5 ms·

Hi HN! Wrote this up based on our experiences working with early adopters of GraphQL and serverless. There have been lots of teething pains with serverless arc

Hi HN! Wrote this up based on our experiences working with early adopters of GraphQL and serverless. There have been lots of teething pains with serverless architectures and we've seen this as being a useful way of pushing business logic to being "serverless" which is run asynchronously and the results are captured asynchronously too. That way you don't have to worry about cold-starts and a lot of error handling and resiliency concerns go into the generic event system. GraphQL subscriptions also fit in really well because they allow clients to consume asynchronous results. Feedback, ideas, experiences very welcome!

zawerf 8y ago
Should list some concrete implementations. For example I think AWS AppSync with AWS Lambda is exactly this architecture as a service.
IMTDb 8y ago
The issue I have with your website compared to the 12factor one is how hard it is to grasp/implement your advices. > 12Factor Nbr 3 : Store config in ENV variables. Yep I can do that. In 2 hours I can convert most of my conf in env var. And my next project will go with ENV var from the start. > 12Factor Nbr 11 : "each running process writes its log, unbuffered, to stdout" Yep, give me 5 minutes to do that. When I read 12 factor, and decided to give it a shot, by the end of the week, my app (2 devs full time for 2 years) got nearly everything nailed down and I was able to benefit from it. The last remaining points were harder to implement but I undestood what I needed to do and why. Most of the advices of the 12factor manifesto can be applied to any programming language/framework/architecture/buisiness and make the deployment/management of the app at least easier. When I read your manifest, I did not understand most of it. Even your examples do not "talk" to me : > In your food ordering workflow, instead of writing a payment processing microservice that captures different failure modes, write a payment processing function that processes a payment or fails. The event system should capture the retry or failure event which is processed thereafter. This ensures your business logic is simple and easy to scale. What event system ? how does it capture the failure mode ? I have an app that is now 4 years old, on which 6 devs are working full time, what can I do today to make it better in a month or two ? Why are your trying to force me to use GraphQL and make a tech choice for me ? At no point 12factor says use "HTTP REST JSON API" even is a lot of user will go that road, it's their choice and not forced by the maifesto itself.
- ericfrederich 8y ago
  https://3factor.app/#comparison-to-12factornet https://3factor.app/#comparison-to-12factornet It's an architecture. No claims were made that switching architectures is easy, quick, or even recommended. There should be no comparison to 12 factor. The choice of title did make me click on it though.
- kitd 8y ago
  As mentioned in the article, it's an architecture pattern similar to Redux but applied to the whole system, ie Action -> State -> Event -> Reaction
  - beaker52 8y ago
    It's a shame Redux uses the word Action instead of Event because I think we'd all have easier time discussing Event Sourcing right about now
    - acemarke 8y ago
      It's because Redux was specifically written as "just another library implementing the Flux Architecture", and Flux used the term "action". See Dan's comments at https://github.com/reduxjs/redux/issues/891#issuecomment-147666329 https://github.com/reduxjs/redux/issues/891#issuecomment-147... and https://github.com/reduxjs/redux/issues/377#issuecomment-126589473 https://github.com/reduxjs/redux/issues/377#issuecomment-126... for justification and links to prior discussions.
- tirumaraiselvan 8y ago
  > What event system ? how does it capture the failure mode ? I have an app that is now 4 years old, on which 6 devs are working full time, what can I do today to make it better in a month or two ? Good question. Definitely the wording can be improved. Let me try to explain though. Suppose you write a simple function which processes payment. It fails. Now you can insert a state saying failed with error code 1001. Now this insert creates an event which invokes a serverless function specifically aimed at resolving this error. This way you have smaller cohesive functions which do "atomic" work as much as possible. PS: Co-author here.

zawerf 8y ago

Should list some concrete implementations. For example I think AWS AppSync with AWS Lambda is exactly this architecture as a service.

IMTDb 8y ago

The issue I have with your website compared to the 12factor one is how hard it is to grasp/implement your advices. > 12Factor Nbr 3 : Store config in ENV variables. Yep I can do that. In 2 hours I can convert most of my conf in env var. And my next project will go with ENV var from the start. > 12Factor Nbr 11 : "each running process writes its log, unbuffered, to stdout" Yep, give me 5 minutes to do that. When I read 12 factor, and decided to give it a shot, by the end of the week, my app (2 devs full time for 2 years) got nearly everything nailed down and I was able to benefit from it. The last remaining points were harder to implement but I undestood what I needed to do and why. Most of the advices of the 12factor manifesto can be applied to any programming language/framework/architecture/buisiness and make the deployment/management of the app at least easier. When I read your manifest, I did not understand most of it. Even your examples do not "talk" to me : > In your food ordering workflow, instead of writing a payment processing microservice that captures different failure modes, write a payment processing function that processes a payment or fails. The event system should capture the retry or failure event which is processed thereafter. This ensures your business logic is simple and easy to scale. What event system ? how does it capture the failure mode ? I have an app that is now 4 years old, on which 6 devs are working full time, what can I do today to make it better in a month or two ? Why are your trying to force me to use GraphQL and make a tech choice for me ? At no point 12factor says use "HTTP REST JSON API" even is a lot of user will go that road, it's their choice and not forced by the maifesto itself.

ericfrederich 8y ago
https://3factor.app/#comparison-to-12factornet https://3factor.app/#comparison-to-12factornet It's an architecture. No claims were made that switching architectures is easy, quick, or even recommended. There should be no comparison to 12 factor. The choice of title did make me click on it though.
kitd 8y ago
As mentioned in the article, it's an architecture pattern similar to Redux but applied to the whole system, ie Action -> State -> Event -> Reaction
- beaker52 8y ago
  It's a shame Redux uses the word Action instead of Event because I think we'd all have easier time discussing Event Sourcing right about now
  - acemarke 8y ago
    It's because Redux was specifically written as "just another library implementing the Flux Architecture", and Flux used the term "action". See Dan's comments at https://github.com/reduxjs/redux/issues/891#issuecomment-147666329 https://github.com/reduxjs/redux/issues/891#issuecomment-147... and https://github.com/reduxjs/redux/issues/377#issuecomment-126589473 https://github.com/reduxjs/redux/issues/377#issuecomment-126... for justification and links to prior discussions.
tirumaraiselvan 8y ago
> What event system ? how does it capture the failure mode ? I have an app that is now 4 years old, on which 6 devs are working full time, what can I do today to make it better in a month or two ? Good question. Definitely the wording can be improved. Let me try to explain though. Suppose you write a simple function which processes payment. It fails. Now you can insert a state saying failed with error code 1001. Now this insert creates an event which invokes a serverless function specifically aimed at resolving this error. This way you have smaller cohesive functions which do "atomic" work as much as possible. PS: Co-author here.