4 ms·

Hm...not sure why you think this goes against what you’re saying. The idea is just to make things more asynchronous and give the front end team the ability to c

Hm...not sure why you think this goes against what you’re saying. The idea is just to make things more asynchronous and give the front end team the ability to consume async information. Also, giving the frontend team the power to query what they want is not a bad thing. You should have a process to whitelist queries before they go into prod anyway. Incidentally serverless can also mean microservices. The idea is just to deliberately remove state from inside the code and put it into state or events. And then running that on something that scales 0-n. Why Is that against your principle of scaling the codebase for the team? It’s just a dev principle to make ops easy.

jungturk 8y ago
This approach doesn't prevent doing things well - there's lots to like about eventing and async processing. The distribution of the business logic among asynchronous actors (the serverless message-driven elements) will likely increase the potential for consistency issues at runtime and might increase the cognitive burden on the team at dev time ("where's the right place to put function X", "how do I test scenarios now that they're distributed", "what should my unit do if a collaborator didn't process its events in a timely fashion or at all"). These are all tractable problems, but problems nonetheless.
vikingcaffiene 8y ago
Let me start this by saying I am a frontend developer. Lest you think I am some curmudgeon coming at you with exclamations of the "good ol' days" of PHP/jQuery... I'll give you this: you can build something suuuuuper fast with this architecture. I imagine it would be thrilling for the first, say, 6 months or so. Hell maybe even a year if your business rules don't change too radically. In SV that might well be enough. As long as you are building and not maintaining/updating I doubt you'll get bit too bad. Depends on the size of your team. In this case smaller would be better. Its just that I've yet to see a compelling case for this type of thing for non FAANG companies. They have very very different problems than the rest of us and every one of them started out as a monolith (shoot Google STILL rocks one). To me it makes way more sense to start out as one, maybe two, code bases and then scale off things that need these performance boosts to serverless processes etc as they are needed. The reason being that to be effective in a given system, one needs to be able to understand the ramifications of changes as they are made. Its much easier to do that when you can grok the whole system vs talking to an isolated process. Let me step through your comments/questions: > Serverless can also mean micro services Oh I am aware. Dear god I am I aware... I manage many of these in a given day. These are even worse honestly because they have their own dependency trees and keeping those up to date/compatible is a friggin' nightmare. Then of course there is configuration management. Then there is the case of having to maintain multiple release versions of an app and needing to apply patches to those micro services. Oh and what if you have a multi tenant environment and those are running different versions? Its just a mess. Thar be dragons dude. > giving the frontend team the power to query what they want is not a bad thing On this we disagree. There should be a discussion about this. A pattern to follow and a data contract. The UI should be as dumb as possible and only know about that contract. If that contract is not met, things should go red. I'd be willing to concede that something like a reporting interface or a complex filtering scenario would make sense. I just don't think it makes much sense to let anyone pull down anything they want wherever. > You should have a process to whitelist queries before they go into prod anyway. We agree on this. However, at the risk of sounding snarky, thats what an API contract is. > And then running that on something that scales 0-n Again, this is not a problem you need to solve right away. If/when it does arise, there are a lot of steps you can take that are simpler and easier to manage than a bazillion isolated processes that don't know about each other. Am I saying this is a uniformly bad approach? No of course not. It might make perfect sense for your org. I am just saying that for most of the type of work I've done, the real scaling issues that I've encountered come from premature optimization and unnecessary obscurity.
- tango12 8y ago
  Thanks. This is helpful! One question on the API contract, giving frontend teams power thing: what are your thoughts on things like firebase on the one hand and graphql on the other?

jungturk 8y ago

This approach doesn't prevent doing things well - there's lots to like about eventing and async processing. The distribution of the business logic among asynchronous actors (the serverless message-driven elements) will likely increase the potential for consistency issues at runtime and might increase the cognitive burden on the team at dev time ("where's the right place to put function X", "how do I test scenarios now that they're distributed", "what should my unit do if a collaborator didn't process its events in a timely fashion or at all"). These are all tractable problems, but problems nonetheless.

vikingcaffiene 8y ago

Let me start this by saying I am a frontend developer. Lest you think I am some curmudgeon coming at you with exclamations of the "good ol' days" of PHP/jQuery... I'll give you this: you can build something suuuuuper fast with this architecture. I imagine it would be thrilling for the first, say, 6 months or so. Hell maybe even a year if your business rules don't change too radically. In SV that might well be enough. As long as you are building and not maintaining/updating I doubt you'll get bit too bad. Depends on the size of your team. In this case smaller would be better. Its just that I've yet to see a compelling case for this type of thing for non FAANG companies. They have very very different problems than the rest of us and every one of them started out as a monolith (shoot Google STILL rocks one). To me it makes way more sense to start out as one, maybe two, code bases and then scale off things that need these performance boosts to serverless processes etc as they are needed. The reason being that to be effective in a given system, one needs to be able to understand the ramifications of changes as they are made. Its much easier to do that when you can grok the whole system vs talking to an isolated process. Let me step through your comments/questions: > Serverless can also mean micro services Oh I am aware. Dear god I am I aware... I manage many of these in a given day. These are even worse honestly because they have their own dependency trees and keeping those up to date/compatible is a friggin' nightmare. Then of course there is configuration management. Then there is the case of having to maintain multiple release versions of an app and needing to apply patches to those micro services. Oh and what if you have a multi tenant environment and those are running different versions? Its just a mess. Thar be dragons dude. > giving the frontend team the power to query what they want is not a bad thing On this we disagree. There should be a discussion about this. A pattern to follow and a data contract. The UI should be as dumb as possible and only know about that contract. If that contract is not met, things should go red. I'd be willing to concede that something like a reporting interface or a complex filtering scenario would make sense. I just don't think it makes much sense to let anyone pull down anything they want wherever. > You should have a process to whitelist queries before they go into prod anyway. We agree on this. However, at the risk of sounding snarky, thats what an API contract is. > And then running that on something that scales 0-n Again, this is not a problem you need to solve right away. If/when it does arise, there are a lot of steps you can take that are simpler and easier to manage than a bazillion isolated processes that don't know about each other. Am I saying this is a uniformly bad approach? No of course not. It might make perfect sense for your org. I am just saying that for most of the type of work I've done, the real scaling issues that I've encountered come from premature optimization and unnecessary obscurity.

tango12 8y ago
Thanks. This is helpful! One question on the API contract, giving frontend teams power thing: what are your thoughts on things like firebase on the one hand and graphql on the other?