4 ms·
They have this diagram: +-----------+ +--------------+ +-----------------+ |Web Browser| |Smartphone App| |Client Libraries/| +-----+-----+ +--
by moonchild 6y ago
They have this diagram:
+-----------+ +--------------+ +-----------------+
|Web Browser| |Smartphone App| |Client Libraries/|
+-----+-----+ +------+-------+ |Other API code |
| | +-------+---------+
| v |
| +-----+------+ |
+--------->+ Steveslist +<-----------+
| Servers |
+------------+
Why not this?
+-----------+ +-----------------+ +--------------+
|Web Browser|-->|Client Libraries/|<--|Smartphone App|
+-----------+ |Other API code | +--------------+
+-------+---------+
|
v
+-----+------+
| Steveslist |
| Servers |
+------------+
- monocasa 6y agoDifferent ergonomics of each of those environments, at least in the ideal case for each combined with the server API being a clean enough API boundary if I had to guess.
- filipn 6y agoYes, I think the second diagram that you showed is the preferred way of doing things, since using or "dogfooding" the client libraries will ensure they are always tested and correct, plus you'll get immediate feedback from the other developers who work on the apps as well.
- amarant 6y agoIn this day and age, your client libraries should be generated automatically. And of course used in your apps/webpage to save time. See openapi/swagger for good examples how client generation works
- awofford 6y agoI've been using openapi/swagger for generating my clients and honestly think it creates a mess of files and manually keeping clients up to date is not a huge task. I'm not sure that I buy into "your client libraries should be generated automatically" as a blanket statement.
- kqr 6y agoGranted, APIs aren't updated often, but when they are, generated clients can save a lot of time. I can update a generated client in half an hour and be very confident of its correctness, whereas a manually constructed client would take hours to update and test. Of course, the generated client is not very convenient, being a 1-to-1 mapping with the API. You build a high-level client with the more common operations on top of the generated one. It's possible to do this in a way that gets you the best of both approaches, with some up-front planning.
- TuringNYC 6y agoAnother benefit would be easier testing - you can easily auto-test the logic and separate the testing of the UI.
- bananaface 6y agoNicely wrapped-up public APIs with a pleasant presentation & small learning curve require tradeoffs. Why force your own app & website to pay those costs?
- JamesSwift 6y agoYou dont "force your site to pay these costs", you design your clients as consumers from day one and get consumable external APIs for free.
- bananaface 6y agoHiding the costs, minimising the costs or "integrating them well with your platform" do not erase the costs.
- mattwad 6y agoDo most companies need an external API?
- therealdrag0 6y ago3/4 places I've worked have an external API. It might not be "public" but often enterprise customers want to pull their data for their own mangling.
- haggy 6y agoThis is a common "holy grail" that I've never seen any company pull off successfully. Like others have said you rarely have the ability to build a simple-yet-powerful API that perfectly services both your company proprietary apps and 3rd party clients. The requirements are almost always at odds with each other.
- Pokepokalypse 6y agoIt certainly takes a huge amount of discipline, which is wholly absent in most service companies.
- WrtCdEvrydy 6y agoI think at the beginning you won't have a client API at the beginning. That stuff is only done at the end unless you're chargin for that at the beginning. If you're not B2B positioned, you probably won't have a client library for a while.
- wenc 6y agoWouldn't the issue with client libraries be tight-coupling and having to maintain n libraries instead of one generic server API endpoint?
- bananaface 6y agoYes