People.
There is a difference between a backend and an API.
Taking the endpoints that you wrote for your site, slapping some documentation on them and publishing it
does not make an API.
An API needs designing. It needs a conscious language and consistent conventions.
Standard auth.
Paging.
Careful error codes and messages.
Versioning.
A backend is whatever your front end needs. It should change when your front end needs it to change.
Don’t restrict it to historical behavior because other systems have grown dependent on it.
Don’t publish your back end to some catalog!
Not every HTTP endpoint needs to be an API!
Boundaries, people!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@PhillipaAvery@netflix In the Startup and Growth phases, it's all about velocity. In Maturity, it gets interesting. We need stability without killing velocity.
@PhillipaAvery@netflix In renewal/decline, parts of the software need stability while other parts need velocity.
(I missed the cool picture, it was pretty great)
Today at #QConPlus , @girba shows graphs that reveal hidden dependencies in code.
Somehow this code reveals its own properties and relationships in custom-made developer experiences
Glamourous toolkit: gtoolkit.com
"empowering developers to create their own tools for every one of their problems" @girba#QConPlus
This is a superpower of developers: we can craft our own work environment.
For example, when viewing build logs: as you find a new problem, add some custom highlighting so that next time it jumps right out at you.
Anyone who says to you “this architecture is universally applicable”
is probably selling something,
and not doing a very good job at selling something.
Don’t use event-driven architecture for a small system or for an exploratory spike.
“learn what you’re trying to do before you elaborate your architecture.” @tlberglund#DevoxxPL
Databases don’t go away when you’re using events.
If nothing else: when you need lookup by multiple keys, databases are necessary views on the system of record (which is the event log).
Adding people scales at best linearly upward, at worst geometrically _downward_.
Two things you must constantly seek in order to get more done with more people:
1. "Constant pursuit of force multipliers"
Instead of adding more people to the same task, change the task to be done.
Develop more-complex internal structures, such as tooling teams that facilitate many development teams.