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.
@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).