Justin Karneges, CEO of Fanout, stood up in front of 50 developers at a recent API Craft meetup in San Francisco and painted a picture of a world where APIs pushed data to recipients in realtime. In Justin’s vision, news, stock information, chat, collaborative tools, and games will all be handled with a realtime API protocol called GRIP.
After Justin sat down, Mark Jen, a software engineer at Square, addressed the crowd. Square is a local San Francisco company helping businesses to accept credit card payments. It’s rumored that they were valued at $6 billion last October. Square is using APIs to help their clients develop custom software solutions for a business advantage. For Square, APIs are big business.
API Craft San Francisco kicked off their first meeting of the year with talks on API innovation and business impact. The meetup was hosted by Open Table and organized by Emmanuel Paraskakis. The meetup was started last summer and currently has almost 600 registered members. By a show of hands, most of the 50 people that attended the physical meetup were developers, and most were currently working on an API. It was a quiet, serious atmosphere.
Justin Karneges spoke first. Karneges was previously at Livefyre, a commenting system, with high scale problems and the necessity of building an API. He started out defining realtime. It is programs like news feeds, tickers, chat programs – all applications that push data to recipients with no poles in between. His presentation is available at the link below.
Almost realtime is not the same as realtime. Realtime must be stateful with long lived connections, sockets tied to processes. Publish – Subscribe (“pub-sub”) is the dominant model where you run general purpose servers, subscribers don’t have to worry what language you’re programming in.
Karneges says API creation is different. The way you connect is different. “It’s good to have diversity in APIs.” Simple connectivity is fine. In the standard architecture, if the client is asking for comments after a certain time/date stamp, if the data is sitting in the database, then responding is easy. If the data is not published yet, the client needs to wait, then is served the data in real time. This starts to make decisions harder.
Scaling real time push is all about delegating work, one-to-many publishing, delegating to the edge tier, and scaling at the edge tier, not at the app. Push, on the other hand, can be a disaster. There are no generalized tools, there are proprietary client-server interfaces, everything is engineering-driven, and realtime APIs end up being created by hand.
To make this easier, Karneges has created the Generic Realtime Intermediary Protocol (GRIP) as a common protocol between edge and backend. GRIP uses well-known open technologies like HTTP and WebSocket, REST interface for control, and DevOps can manage the edges how they see fit. GRIP had multiple components, including GRIP flow, GRIP publishing mode, GRIP streaming mode and it allows incredible flexibility from the backend.
Building a Big Business with APIs at the Core
The second speaker was Mark Jen from Square’s external platform and enterprise customer teams. He gave a great overview of Square’s evolving perspective around the importance of API’s and how core they are to building the Square business.
There has traditionally been a large ecosystem for building apps for companies. IT systems, business tools, POS devices, and lots more. All of them entirely closed. Restaurant POS (Micros, NCR) have no APIs, or APIs with big fees, and if you develop using them, there are more fees. The result has been that there was not a lot of innovation. Jen suggested it’s been at least two generations of improving technology generations that have missed out.
Square wants to encourage developers to help merchants to build useful tools, to involve more people in the ecosystem instead of Square doing it themselves, and to create different options for customers. Customers more and more want different ways to view their businesses, open ecosystem can respond best to those needs.
Jen also discussed in detail the main Design Considerations at Square. First, time to live (TTL) for developers, how long will it take you to go from zero to 60 when you start developing? Square is aiming for less than 5 minutes. The Square dev portal is easy to log into, can use curl requests to get started, then hack together your specific project. This is extremely useful for initial testing and quick prototyping.
Also, Square always tries to start small and iterate quickly. Along with that thinking is close connections to early testers. When Square rolls out endpoints, they prefer to start private, add partners, and publish docs. For new APIs, they like to work with trusted partners during design, development and initial launch. It’s a constant issue on how to balance partner requests with general usability.
And they believe backwards compatibility is important. They have license to add fields at any time, but never take away fields and never rename fields.
For Square V2, there are multiple improvements they are considering:
- Representing time as RFC3339 or unix timestamp mills instead of ISO8601
- Stop scoping everything by merchant ID
- SDKs could be a huge win, especially when you update your server API; how to keep them idiomatic and updated?
- Universal ID (guid/uuid) instead of internal data-type specific IDs
- Ability to attach arbitrary metadata to any Square entity
The final Q&A session produced quite a few relevant questions.
How does Square do documentation? The real answer is that we have one guy with LaTex, then from there docs are turned into PDFs, etc
What do you do for monitoring? Started with nothing (surprise!) but now very comprehensive, can see patterns and suggest ideas to partners, batch summaries at the end of the day versus regular sync jobs to make sure inventory is constantly up-to-date
How do you handle outages? Basically set up Nagios with paging, so Square often knows of problems before partners. Square has a special relationship with Intuit that delivers vmail through paging. Square also uses Stackoverflow to a certain extend but the asynchronous nature means questions might not get noticed or don’t contain enough details and needs some back-and-forth to clarify
Have you tried to build One API to Rule Them All? Initially thought this was a good goal to have: internal and external, just add and make everything available to everyone. That line of thinking versus move fast, iterate quickly. The two don’t mix well. So Square cautiously operates in an internal/external mode. Which means the first test internally on a limited level, and publish for everyone after there’s high confidence that it’s polished and useful for multiple use-cases
The API Community
Due to the rapid rate of innovation in API technology and the impact APIs are having on businesses, the API community of developers is a critical part of our learning experience. Around the world, hundreds of meetups like API Craft San Francisco feature API developers helping each other. If you seen cool things that would benefit the community, please add it to the comment section below.