Slow requests to payment gateways or sudden spikes in image uploads make background jobs crucial to scaling applications. However, they require us to think differently about failure scenarios: we give up consistency guarantees, and we can’t be certain if or when a job will succeed. In this talk, you’ll learn how to make the most out of background jobs as well as how they are used at Shopify to scale one of the largest running Rails applications.
I'd like to show off my setup that we use at Leaplines for making React development with graphql/react/webpack and Ruby as painless as possible. We've used this setup over 8 apps and it allows up to build reactive applications fast and easy.
Now building JS apps almost becomes as productive as standard Rails apps!
Do you struggle with slow application? Is New Relic not giving you any valuable insight? Maybe it's always the same controller or maybe it's (what seems) completely random. How do you tackle that? [Flame Graphs](http://www.brendangregg.com/flamegraphs.html) are the answer.
I'm fascinated by Flame graphs and how they work. I also find it surprising not many people use it.
I would like to discuss a very simple approach to get the best of both worlds.
Covering topics such as Authentication and Authorization, Communication with REST and GraphQL and Deployment.
Current application state; what, in fact, is it? We, as software engineers, usually don’t think much about it (unless we face a consistency issues in a distributed system, in which case we might think about it a LOT).
Looking closer, one might realise, in essence what is known as current state is just a product of mutations over time. Mutations which, as they happen, commonly cause the software system to forget about what was, up to that point, known as current state. Once this becomes clear, one starts to wonder, is there a beneficial way to utilise this fact?
Starting from a perspective of "classic" n-tier system architecture, I will explore benefits and potential downsides starting with formally splitting r/w requests into commands and queries , recording state mutations as events, ending with a solid system capable of time travel and some other, potentially unexpected superpowers including, but not limited to, precognition, "roflscale", and self reconstitution.
Server side rendering still the thing! As well as separation of concerns.
In this talk I'll share my experience of using Stimulus in production, common approaches, common pitfalls and ways to workaround it.
ActionCable is super easy to setup and offers a nice and clean way to open a websocket connection.
I would love to hear about experiences with it in real-world applications. How to handle request/response use-cases? For which type of applications do you use it? Does it scale?
Want to add a contribution or an interest? What are you waiting for?