Hacker News Reader

Ugh, last time I worked on a project that did this the API ended up designed by "an architect" to provide data that the back end didn't have and the front end didn't want. It was an unmitigated disaster.

Outside in drives a much more effective requirements discussion as you work your way down the stack. If the front end asks for data that's "too complex to retrieve" then that's usually obvious from the mock up and it is cheaper to change it at that point before code lower down the stack has been written.

It leads to much cleaner API design and better negotiations about what should go where since the written code of the layer above effectively drives the requirements for the layer below.

I'm not disagreeing with the architect part -- that's what I meant by "Once you've verified that the API design works for the needs of both ends".

An architect working in a vacuum is only going to result in unmitigated disaster in my experience. :)

But I disagree where you say that it's usually obvious from a mock-up that the backend is going to be too complex. In my experience that never occurs to people at all. All too often I've seen designers spend months mocking up fantasy functionality while the backend team is drawing up tables, shards and microservices, only for it to eventually collide in total incompatibility, when the front-end developers say "but the back end doesn't let us do three-quarters of this!" and the back-end developers say "but obviously you can't get the data that way, what ever made you think you could?"

Forcing the API conversation/specification to happen at the start, rather than in the middle, forces extreme clarity for both sides, so that necessary critical compromises are hashed out at the beginning, instead of discovering a horrible incompatible collision midway through.

> designers spend months mocking up fantasy functionality while the backend team is drawing up tables, shards and microservices, only for it to eventually collide in total incompatibility

that's because this methodology is called waterfall, and it has proven to not work, time and time again.

The project should not start with full requirements - it should start with a single requirement/feature (even if that feature by itself doesn't fullfil the purpose of the software). What is the topmost important feature? Do that part first, and have it working end to end. It should take as little time, and done as fast as possible. It should allow the design team to create as simplified a design as possible, and allow the backend to use as simplified a backend as possible. It should allow testing to be done well (good coverage, good unit testing etc).

Then once this is done, the client will judge it, and say what can be improved. Do that one improvement, only, before going back to the client and repeat.

This has been what most successful projects done.

Obviously this is a complex topic but this applies equally well to agile as well as waterfall.

If you're planning your sprint, the point is to figure out the API call first together, before work starts on either front end or back end.

Real-world projects exist on a wide continuum between "maximum agile" and "maximum waterfall", and usually fall somewhere in between. You can't build AWS or Google Search purely out of 2-week sprints with no further advance planning or specification. :P

>Once you've verified that the API design works for the needs of both ends.

Which was easy to do in retrospect or half way through the task, but doing that verification step up front didn't work.

IMO backend constraints are usually less stringent than the frontend part. Mocking the front first avoids a lot of designing round trips I think.

For instance if on the frontend you need to display an infinite list of items, how you get your data can be heavily influenced by your interface. If you plan on having a super fast scroll with the user flying through the items, you might want to do it differently than for a page by page site.

If you design API first you must make this choices upfront, and you paint yourself in a corner if you change opinions when the resulting UX is in your hands and you’re playing with it.

Front (prototype) -> middle -> out

> Always define the API first

Impossible. What will the API serve? A list of horses? Wouldn't work if the user needs a mortgage calculator. There is no choice but to define the front-end first. The question is whether it's defined nebulously or with thought - it's rare for thoughtlessness to be the optimal strategy.

For backend engineers who have trouble understanding that the front end is what all the work is in service of, tell them that the frontend us the Tests for their Test Driven Design.

I say this as a backend engineer. The backend genius shines when we figure out how to serve the frontend efficiently (low compute cost) and adapt to rapidly changing frontend requirements without delaying releases.

The change I'd make here is around "locking down" the API design.

One of the biggest benefit of starting with the API is that both the backend and frontend devs can start playing with that contract, and discovering the nitty-gritty ways where it's less ideal than you'd hoped when you designed it pre-code.

So you get to pressure test it, and iterate on it, from both sides, instead of just from one of them.

>Figure out the information necessary, and make sure it meets both front-end constraints

Seems to be a glaring contradiction. How would you know if it met front-end constraints if you haven't defined the front-end yet?

My experience is that front-end is king. It defines what the app must do. The API and back-end are the how. Obviously, you need the what before the how.

If you run into a constraint, then you figure out how to work around it, or what can be sacrificed while still having the front-end deliver the what.

That is usually the best approach. It can still bite you in the ass, though.

Sometimes that approach leads a project into a cemented API and new requirements that arise after real world application can be even harder to implement as a result.

So I guess I’m not arguing, but agreeing while adding that the approach needs a couple qualifiers.

Yup! And reference Ivar Jacobson's OOSE: Use Case Driven Approach for just how long of a history this successful approach has had.

In most cases API comes last, after the data and UI. This is just the state of things unless you intentionally building an api service from scratch. Data stays forever and in many times serves more than one application, UI changes all the time and might connect to more than one data source. API is the decoupling between those two and in most cases dictated by both, not the other way round.

No, the data is always coupled to how it is intended to be processed and useless otherwise. Integration is always a giant headache on projects that don't capture intent clearly with a good API.

Silicon Valley lives on! iirc there were actual companies started with "middle out compression"