The ‘Backends for Frontends’ Pattern at SoundCloud
thoughtworks.com
The ‘Backends for Frontends’ Pattern at SoundCloud
1–10 of 26 posts
Re: The ‘Backends for Frontends’ Pattern at SoundCloud
#2Re: The ‘Backends for Frontends’ Pattern at SoundCloud
#3Ultimately you should separate teams by the functionality they're supporting, not by which part of the stack they're notionally in. One interesting approach is to pair-program at each step - designer and frontendey dev do the page, frontendy dev and backendy dev do the front half of the backend, backendy dev and DBAey dev do the data access layer.
Re: The ‘Backends for Frontends’ Pattern at SoundCloud
#4Are they in the "search for the developers" /quick grow phase?
Re: The ‘Backends for Frontends’ Pattern at SoundCloud
#5Re: The ‘Backends for Frontends’ Pattern at SoundCloud
#6I love the diagrams on this blog post. Does anyone know if they're hand-drawn or if there's a tool that produces them?
Re: The ‘Backends for Frontends’ Pattern at SoundCloud
#7I love the diagrams on this blog post. Does anyone know if they're hand-drawn or if there's a tool that produces them?
Re: The ‘Backends for Frontends’ Pattern at SoundCloud
#8Interesting to see this creates new problems, such as blocking calls to dependant services downstream, and what services you declare as critical or not. Also duplicate code is unavoidable. So if you're attempting this pattern, keep those things in mind since you will have limited technology choices.
Sound Cloud is using Scala here. https://developers.soundcloud.com/blog/building-products-at-...
Edit: Found their mention of technology
Re: The ‘Backends for Frontends’ Pattern at SoundCloud
#9Re: The ‘Backends for Frontends’ Pattern at SoundCloud
#10This pattern is essentially what technologies like GraphQL or Falcor make super easy. My GraphQL server talks to a bunch of microservices and presents a simple clean API for my web application, largely freeing the front-end from years worth of bloated APIs.