Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gravitee: Open-Source API Gateway

gravitee.io

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Gravitee: Open-Source API Gateway

#41

Post by Bombthecat »

chimen wrote: post #30
whoisjuan wrote: post #3

Why none of these API gateways offer monetization out of the box? I'm curious. Is that a not well-demanded feature? I have researched a lot of them and none have a straight way to do metered billing and if they somehow do, they are prohibitively expensive. Does somebody know of an API gateway solution that offers this?

In the same boat. I think you can do something with API Gateway + API Marketplace but I would LOVE a plugin to Kong or any other OS software...even if it would support just one gateway. $500 for Apigee makes it untouchable for small startups. Another one worth looking into might be at IBM bluemix.

Axway api management might be another alternative.

Re: Gravitee: Open-Source API Gateway

#42

Post by Bombthecat »

fosk wrote: post #25
sheeshkebab wrote: post #21

Running these api gateways on your own is very complex, especially when they need to be open publicly. Typically you’d want to layer a WAF and a CDN on top of them, which already come with their own api gateway like features (eg AWS cloudfront). My question - what do people use these for?

API Gateways back in the days were primarily being adopted at the edge for external traffic, but they are increasingly being used internally to connect teams/products together, or in a Service Mesh deployment pattern for microservices. Solutions provided by cloud vendors are generally not well suited for all the N-S and E-W use-cases that typically an organization requires, they are usually slow (which in turn preven…

Yeah, my current project is using an internal / external api gateway style. You run into so many issues... You kinda want to run away (beside performance) it is super hard to actually manage / govern etc..

Re: Gravitee: Open-Source API Gateway

#45

Post by jgrahamc »

fosk wrote: post #11
jxub wrote: post #9

Earlier quoted context omitted.

API Gateway is closed source for one. Kong is written in Lua, for better or worse.

Hello, Marco here (CTO of Kong). Correct, Kong is primarily written in Lua with some bits in C, for two particular reasons: low latency and very high performance. Lua per-se is a fast language (having a very small footprint), but running Lua on top of LuaJIT [1] is just so much faster. LuaJIT is an alternative implementation of the Lua VM created by Mike Pall and now supported by a few other folks and organizations l…

Yes, that's right we do have a large Lua (using LuaJIT) code base but we are moving away from it.

Re: Gravitee: Open-Source API Gateway

#46

Post by NicolasGeraud »

Hi, I'm Nicolas (CEO of GraviteeSource, the company behind Gravitee.io).

We provide a full featured api management platform (gateway, dev portal, analytics, ...).

We use Eclipse Vert.x and every plugin is written in java.

The comparison between Gravitee and other competitors depends on your use case (saas/onprem/hybrid, features ootb, api gateway or api management, ...).

If you have specific concerns, please ask.

Re: Gravitee: Open-Source API Gateway

#47

Post by loeg »

fsfod wrote: post #28
loeg wrote: post #18

Earlier quoted context omitted.

tl;dr: Lua is a GC language and that's where the variance comes from.

As the co-author of that blog post a more accurate tl;dr would be the variance comes from shared hot counters that collide based on the address of objects.

Ok, to resummarize: LuaJIT is a JIT'd interpreter for a GC'd language and those two factors are where the variance comes from.

You found some very low hanging fruit in the JIT engine in particular (64 global trace buckets), fixed it and at least threw it over the fence upstream (and kudos for that). But you buried it in a bunch of irrelevant figures, and at the end of the article you rediscovered GC pauses. GC pauses are a classic, well-known problem with GC languages.

My critiques are this:

1. There is a huge body of prior work and analysis of JIT'd and GC languages due to the outsized impact of Java, probably the most popular language on the planet at one point (if it isn't still). (And Golang — Java 2.0.) Java's history (and perhaps Golang's more recent history) should have been top-of-mind at the outset of this project. I think you could continue to apply lessons learned from abundance of experience around Hotspot and JRE tuning to the LuaJIT interpreter.

2. The lengthy benchmark spreadsheets seem like a distraction rather than a useful tool. They're certainly not adding much to the article and could be summarized in 2-3 sentences each. If you really felt like it, they could be linked to an external appendix.

Post reply on HN