I want to know and be able to build what cloudfare did with nginx.
Figure things like: why request buildups happens on nginx whereas haproxy works fine.
And in the end architect the distriuted to localize failures and not affect rest of the system.
Thank you,
The honest answer to the question "How can one learn to build API gateways?" is unfortunately "Go and build some API gateways and reflect on what you learned at each step perhaps teaching others as you go". This isn't specific to API gateways - it's the way to learn anything effectively.
Your use cases, edge cases, opportunities and pitfalls will be different from mine. Write them up, share them online (including here), so others more like you can learn when doing paper research, much like the research you've done now.
Realise that next time you might need to do it differently. Name the reasons why those needs differ. Write that up. Share.
It's still a youngish field that we're still trying to get right. If the existing books and blogs aren't doing it for you, it's time to figure out why and contribute back.
Not on a technical slant, but here is a good, pragmatic API design guide by Vinay Sahni that I came across a couple of years back [0]. It gave me a ton of good ideas on how to design the API for our SaaS app.
I quickly looked at it and "don't use envelopes by default", "paginate using Link headers" contradict what http://jsonapi.org/ specification says. json:api might not be the best standard and there might be better ones but using something that has many implementations in different languages is better that rolling your own.
Writing a book on this subject would be a fairly pointless exercise as it will age very quickly. You would be better off looking for "how we did xyz" type of blog posts from notable sources.
There are also academic-style papers from Amazon's team on creating high-reliability systems and such. These are worth a read too.
Writing a book on this subject would be a fairly pointless exercise as it will age very quickly.
The technology that we use to implement APIs changes but the fundamental reasoning doesn't. A book about building APIs doesn't really need to talk about specific technologies. Personally speaking, I think the principles that drive the design of APIs I build today are the same as the principles I was using 20 years ago; plan your data structures, include extensible structures for future unknown things, don't make anything trivially enumerable, use HTTP verbs consistently, and document the hell out of everything with working examples that have automated tests so you can easily fix them when the API changes. If you do all that you should end up with a nice API.
Your use cases, edge cases, opportunities and pitfalls will be different from mine. Write them up, share them online (including here), so others more like you can learn when doing paper research, much like the research you've done now.
Realise that next time you might need to do it differently. Name the reasons why those needs differ. Write that up. Share.
It's still a youngish field that we're still trying to get right. If the existing books and blogs aren't doing it for you, it's time to figure out why and contribute back.