PostHole
Compose
Login
SE Radio 576: Jens Neuse on Back Ends for Front Ends
Jens Neuse, founder of Wundergraph, joins SE Radio host Jeff Doolittle for a conversation about back ends for front ends, or BFF. Jens begins by explaining how a heavy integration burden is often placed on front-end development teams. When multiple APIs must be integrated, it can be challenging for client development in web, mobile, and desktop environments. Explaining how APIs should be treated as dependencies, just like packages, the episode explores BFF patterns and use cases, as well as the future potential emergence of a "git for APIs" standard. This episode is sponsored by ClickSend.
Jens Neuse, founder of Wundergraph, joins SE Radio host Jeff Doolittle for a conversation about back ends for front ends, or BFF. Jens begins by explaining how a heavy integration burden is often placed on front-end development teams. When multiple APIs must be integrated, it can be challenging for client development in web, mobile, and desktop environments. Explaining how APIs should be treated as dependencies, just like packages, the episode explores BFF patterns and use cases, as well as the future potential emergence of a “git for APIs” standard.**
This episode is sponsored by ClickSend.
SE Radio listeners can get a $50 credit by following the link below.
Show Notes
From the Show
- A Philosophy of Software Design by John Osterhaut
From IEEE Computer Society
From SE Radio
- 557 – Timothy Beamish on React and Next.js
- 542 – Brendan Callum on Contract-Driven APIs)
- 520 – John Ousterhout on A Philosophy of Software Design )
- 422 – Michael Geers on Micro Frontends
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Jeff Doolittle 00:00:18 Welcome to Software Engineering Radio. I’m your host Jeff Doolittle. I’m excited to invite Jens Neuse as our guest on the show today for a conversation about backends for front ends. Jens is the founder of Wundergraph, a next-generation BFF framework designed to optimize front-end, full stack and backend developer workflows through API composition. He is also the creator of graphql-go-tools, a Golang-based open-source project to build GraphQL middleware proxies and API gateways used by many GraphQL API vendors in the industry as well as many enterprises. Jens welcome to the show.
Jens Neuse 00:00:56 Hi Jeff. Thanks for having me.
Jeff Doolittle 00:00:58 Absolutely. In a recent conversation you and I had, you mentioned that a lot of front- end development teams bear the burden of integrating with lots of distinct APIs and it seems like there’s always new dependencies that they’re taking on. So from a high level, from your perspective, what can be done to reduce this integration and coupling burden?
Jens Neuse 00:01:17 Yeah, I think on a high-level perspective, what we currently see over the last couple of years is we decompose larger systems into smaller parts. We use more and more SaaS systems that provide individual APIs to solve a very specific problem. And what we’re actually trying to figure out is what is the right place to integrate all those systems into one unified API interface? And obviously there’s different places where we can handle this integration and I would say from a frontend developer’s perspective, it can be a huge pain if you have to do all of that with almost no tools that help you facilitate that, do it in the front-end. There’s security pitfalls, but also most front-end frameworks if you look at what they are actually good at in terms of, you know, binding data to the user interface and facilitating that. But what do front-end frameworks have to offer for this modern development use case where you want to integrate with multiple services and most of the time there’s really barely anything. So you’re looking for new ways to solve that problem. And I think that’s a huge challenge for front end but also full stack developers.
Jeff Doolittle 00:02:42 So it sounds like you’re saying that the frontend frameworks, while they may be useful, they’re not necessarily helping solve the challenge of how do I integrate with a bunch of different APIs as a front-end developer?
Jens Neuse 00:02:53 Yeah, exactly. And I actually think this is also a good thing because not necessarily is it the right place to solve that sort of problem. And I think the UI frameworks like React NextGen views, I think the way they are scoped is really great. And usually what you find is that you have this one front-end and it talks to this one API, that’s your backend. And that works very, very well. However, as we said earlier in the discussion, we see that we have more and more services and integrations we want to build with and then we have Payments and Stripe and other SaaS services for sending SMS and whatnot. And we have so many different systems we’re now using, I think for example at Wundergraph, we have at least 40 different vendors that we use ourselves that provide something to us. If you want to integrate all of that in the front-end or wherever you actually want to integrate that, it’s a challenge by itself.
Jeff Doolittle 00:03:57 Yeah. What’s maybe one of the worst things you’ve seen from a front-end integration standpoint? I mean, you just mentioned 40 vendors, so you have 40 vendors and they all have their own APIs. I mean, have you seen situations where front-end teams are literally bearing the burden of trying to integrate tens or dozens of different APIs together in the front-end?
Jens Neuse 00:04:14 Well, I think one of the obvious problems you can very easily see and that it simply shows the struggle of especially younger front-end developers, is when people go to stack overflow and ask where do I put my environment variables into my React application? And you see from the way how they phrased that question, it’s kind of obvious that yeah, obviously they like you should never put a secret of sort or an API key into your React application. And I think there’s a kind of like a gap in education and we need to talk more about, you know, composable architecture and different roles and responsibilities. Like what kind of logic should sit in the backend, what kind of logic should sit in the front-end? And for me personally, worst case you have a front-end that talks to many different systems with different protocols.
Jens Neuse 00:05:15 All the integrations happens in the front-end. You get huge waterfall requests when you visit a new page. Requests depend on requests, depend on more requests, you have like lists and then nested fetches, it all goes to different services. And at the end of the day, for me, what’s the biggest nightmare about this kind of architecture? You actually don’t really understand what this application depends on. And it’s very, very unclear if something is slow or doesn’t properly render or you’re unhappy with the scores your website gets in like Lighthouse, which is a performance check for websites, you don’t really know what’s the cause and it’s just very hard to track that down.
[...]