Month: April 2023

Article originally posted on InfoQ. Visit InfoQ

Chinese internet technology company Bytedance and Valor Software recently open-sourced Rspack, a web bundler written in Rust that aims to be a fast, drop-in replacement for Webpack. Some early benchmarks show a 10x improvement in cold start time.

Bytedance started developing Rspack to slash down production build times that had grown to ten minutes or even half an hour in some cases. Cold start times could also exceed several minutes. To alleviate the cost of migration and keep the flexibility and production optimizations offered by the Webpack configuration mechanism, Rspack was designed to have the following features:

• Fast Startup: Based on Rust, the build speed is extremely fast, bringing you the ultimate development experience.
• ⚡ [Hot Module Reloading (HMR)]: With a built-in incremental compilation mechanism, HMR is extremely fast and fully capable of developing large-scale projects.
• Webpack Interoperable: Compatible with the architecture and ecosystem of webpack, no need to build the ecosystem from scratch.
• Batteries Included: Out-of-the-box support for TypeScript, JSX, CSS, CSS Modules, Sass, and more.
• ️ Production Optimization: Various optimization strategies are built in by default, such as tree shaking, minification, etc.
• Framework-Agnostic: Not bound to any frontend framework, ensuring enough flexibility.

Observed speed improvements will depend on equipment, project structure, and size. Bytedance’s benchmarks apply publicly available Webpack benchmarking tools to a custom codebase. Those benchmarks indicate over 10x improvement in development cold start vs. Webpack (with Babel); and 3x improvement in incremental build time. Nx reported similar results on its codebase:

We ran some initial stats also on our end and we saw some cool improvements. For large components, Rspack was about four times faster than the Webpack implementation. The dev server started like five times faster than the current Webpack implementation and we saw some overall four-and-a-half times faster production builds.

While Rspack was only recently open-sourced, it has been developed for already a year. Nonetheless, the project is still in its early stages and lacks many Webpack functionalities. The Rspack team emphasized that they plan to further increase their support of the Webpack ecosystem:

Rspack is compatible with Webpack’s configuration schema and loader architecture. You can seamlessly use familiar loaders such as babel-loader, less-loader, sass-loader, etc. Our long-term goal is to fully support the most popular loaders including more complex cases such as vue-loader. There is still a big gap to reach the full capabilities of Webpack. Prioritization will be based on community feedback, so please tell us about your requirements!

Rspack was started by ByteDance’s internal platform development team. Internal developer platforms in particular and platform engineering teams in general are being increasingly used by businesses as part of their DevOps practices.

Rust is increasingly being used by web toolchains to dramatically improve performance. The popular Parcel bundler announced last year a new CSS parser, compiler, and minifier written in Rust (100 times faster than JavaScript-based CSSNano and 3 times faster than Go-based ESBuild). Two years ago, Parcel 2 already featured a Rust rewrite of its JavaScript compiler (with up to 10x build performance improvement). Front-end toolchain Rome released a few months ago a Rust-based linter and formatter with one or two orders of magnitude improvement over ESLint and Prettier. Rolldown is yet another effort in progress offering this time a Rollup-compatible API.

Webpack, Parcel, and Rollup are among the most popular bundlers used to build web applications.

Rspack is open-source software distributed under the MIT license. Feedback is welcome and should follow the contributing guidelines and the code of conduct.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Iqbal: My name is Asif Iqbal. I currently work for a company called Couche-Tard, as a global director of digital and experience design. What that means in English, my teams are responsible for the website for North America, Canada, and Europe. My teams are also responsible for all the different native apps, we have quite a few, in Europe, North America, and in Canada. Part of this digital transformation journey is to bring all those mobile apps into one and obviously build omnichannel capabilities. In addition to mobile app and website, my teams are also responsible for experience design. It’s our job and the team’s responsibility to ensure that we have a consistent brand across all the digital channels, so website, mobile app, and what we call unassisted channel, so digital channel. That’s what I do right now. I have about 19 years of experience successfully leading a large digital transformation in wireless, retail, mobile, and e-commerce domain. Of course, very excited to be here to share my digital transformation journey with you: good, bad, and ugly. Yes, there were some ugly digital transformations that I was part of. What that taught me was, what to do, what not to do, who to work for, who not to work for, and how to build teams.

A little bit about my experience. I had an opportunity to work with some great organization and learn from great team members, mentors, and bosses. Also, work for great organizations, the likes of Nordstrom, Walgreens, T-Mobile, Sony PlayStation, and obviously currently with Couche-Tard. In between, I had two years of opportunity and experience to work as a consultant in the consulting domain, which was awesome, actually great. I decided to go back to the corporate world to go back and work on a digital transformation. That’s where the Couche-Tard comes in. I started working for them earlier this year.

Digital Transformation – What Is and What Isn’t?

Once again, here to share my insight, my advice, and my experience, on how to bring digital transformation to your organization. I think it’s important to understand, what is digital transformation to me, because it can be different for anybody, for you or for your organization. It’s important to understand, what is digital transformation to me? What is it? Digital transformation is a mindset shift to enhance and create new opportunities for a business by changing how we operate and deliver values to customer and your shareholders. Why? Digital transformation, if done correctly, increases the development velocity, business agility, and delivers value to customers and your shareholders faster. It does. What is not digital transformation? This is not a digital transformation. I was part of a digital transformation where we literally ported everything from the legacy website or .NET, over to the cloud and said mission accomplished. Please don’t do that. Lift and shift is not a good strategy. The approach often costs more in the short run and in the long run. At another company, we actually reviewed and evaluated the existing web features to ensure what we have, who’s using it, how often that feature is being used. Then we built it using the cloud native tools to ensure efficiency and optimization. Remember not to do lift and shift, which is where we ported everything from .NET over to the cloud and said mission accomplished. In this case, we evaluated the features to make sure who’s using it, how often it’s being used. Then we built it using the cloud native tools with appropriate CI, CD, and CT, and obviously with robust telemetry. If you’re wondering what CI, CD, and CT is, continuous integration, CD means continuous deployment, CT means continuous testing. Robust telemetry, the point of that is that whatever you build, make sure that you have a way to measure it. Having good KPIs, making sure your customers are using it, making sure where the bottlenecks are. If you have no way to measure it, you cannot improve it.

Overview

With that clarification of what digital transformation is to me, because it can be different for others, for your organization, for you, for whatever, which is ok. I will talk about modeling patterns for digital transformation that has worked for me. Four patterns that could be helpful for your digital transformation are, understanding your customer needs and habits, aligning with your cross-functional teams, listening, influencing, and coaching. Of course, measuring, communicating, and celebrating. At the end, I will share the case study from my team’s current effort towards digital transformation.

Customer Segments and Needs

My professor at Ross will be so proud that I am finally using one of his models from the B School. If you’re wondering which B school I went to, I went to the great University of Michigan, Go Blue. Let’s look at this model. This model is so simple but important. What is it saying? Always think strategically. Means, what are the aspirations of your company? How do you compete in the market? What is required to be successful? Who are you competing against? In other words, what, where, and who? Before you do anything in life, especially in digital transformation, you have to know what you’re doing. Where are you doing? Who are you doing it for? What, where, and who? Once you’re aligned on what, where, and who, or once you’re aligned on the strategic thinking, then you go and listen to your customer. Understand their needs. Create personas to understand, who they are. What they’re looking for. How often she shops. Who does she shop with? What time does she shop?

As one of my favorite CEO from T-Mobile, always used to say this, John Legere, “Listen, and do whatever your customer tells you to do. They’re always right.” If you Google this saying from John Legere, you may notice that he may have dropped the F-bomb in there somewhere. Finally, experiment and gather feedback through research, indirect or direct customer feedback. Always start small with time box. Keep the egos at the door, find something quick, and fail forward. What does that mean with those two comments that I just made? The idea is that, get customer feedback directly or indirectly. You can do that through multiple means. You can do moderated testing. You can do unmoderated testing. You can put a simple survey page on your mobile app or on your website, or whatever feature you’re building, and ask for feedback from your actual customers who are using it. Again, get direct or indirect customer feedback.

The comment about always starting small with a time box. What I mean there is this, if you have a great idea, or if you have any idea, or an idea, work with your leader to prototype that idea, try that idea. Do that with the time box in mind. Go and say, I need one sprint of work to do this prototyping to see how a customer takes this and how this idea works. Worst case, do it for two sprints, so 1 month. After that one month, or the timeframe that you’ve picked, if the idea doesn’t work, it’s ok, fail forward. It’s not that your idea was bad. Again, that’s where the ego comes in. It’s not that your idea was bad, maybe it’s not the right time for the idea. Shelf the idea. Go innovate something else, or come up with a new idea. Things like that. Again, fail forward. Try quickly. Prototype it. If it works, great. If it doesn’t work, you’re not going to get dinged by your organization. If you do, then maybe that’s not the right culture or organization you want to work with. The idea is that, always have a fail-forward attitude. An important quote from Steve Jobs, “Get closer than ever to your customer, so close that you tell them what they need before they realize it themselves,” that is, iPhone. Interesting story here. I’m sure there’s still a company in Canada, who were in the mobile business. When iPhone came out, this company’s comment was that customers will never adopt this new device, because they are so used to working using the keypad or keyboard on their device. Fast forward, we know where that company is right now, and where iPhone is, or where the smartphone is.

Aligning with Your Cross-Functional Team

No one person or team can do all by themselves or in a silo. It’s important to invest the time on aligning the why with your team, the stakeholder, cross-functional team. Please, clearly articulate what’s in it for them, not for you. Understand that your team may not embrace transformation because they’re worried about their skills or lack of. Invest in relationship and show empathy. Support and train and empower your employees and your customers and your stakeholder. What does all that mean? Let’s say you go to a company, and you’re responsible for digitally transforming from point A to point B. Now you know that you have your team members who have been working in this point A system for the last 15 years. You come in and you say, we’re going to go from point A to point B. You know what your team’s first response will be? They’re going to be, what happens to me? I don’t know what point B is. What happens to me, does it mean that I’m going to lose my job? Empathy, put yourself in their shoes. Or your customer, when I say customer, I’m talking about your business partner, they may go and say, “I’ve been using this Excel macro for the last 15 years to create an order. Now this new guy is coming in, and he’s telling me that they’re going to digitally transform and all these ordering will be done by looking at the sales curve, order history, past history, how the demand is, that stuff.” Her first reaction will be, “I’ve been doing this for the last 15 years, and we’ve been very successful. Why should I change now? What are you talking about?” If you go with a little bit of different mindset, you go and explain to them the why behind it. It could be as simple as, “Whatever you guys have done for the last 10, 15 years, it was great. It got our company to this point. In order for us to get to the x billion-dollar company, we can’t keep doing the same thing and expect different results. We need to innovate. We need to do something different.” Again, explain the why. That’s number one.

Number two is, with your own team members, maybe have a conversation saying, “We’d like to go from point A to point B, and this is the reason why we want to do it. If you’re worried about not knowing point B, we will help you train it. We will help you get there.” From your business partner’s perspective, obviously, here you have to have credibility chips. Once you have enough credibility chips, what you do is you work with them and say, “How about take a small department in your area and implement this new ordering process in that one system, one department, and wait for one quarter and see what the results are?” I guarantee you if you go with that mindset, and if you see the results, at the end, the people who were a little surprised with what you were asking them to do, they will become your biggest advocate. It has happened to me. I’m telling you, it always works. Again, understand the why, explain the why, and show empathy. Again, invest in relationships. Of course, having a good framework also helps. What does that mean? Make sure you have clear objectives. What are your North Stars? What platform are you going to use? Why are you going to use it? What key expenses you’re going to deliver. When are you going to deliver it? How are you going to deliver it? Digital transformation is a journey. It takes time. It will not happen overnight. If any vendor or third party or some hotshot person comes from the FAANG and tells you that he can digitally transform your company, trust me, run away. It’s not possible to do it overnight. It takes time. It can take over 9-plus months to digitally transform your organization.

Since we’re talking about framework, here are some of the frameworks that I have used. For consistent branding and experience, I have used design system. To help with the prioritization, we have used WSJF methodology. Of course, always strive to create a flexible architecture with continuous delivery in mind. Finally, you don’t have to do or know all. Leverage partnership to gain awareness. Don’t reinvent the wheel, but stay ahead of the curve. What does that mean? Here’s my philosophy about buy versus build. If you are trying to get a competitive advantage and want to build a killer feature in your app, or killer feature on the website that your competitors don’t have, or you cannot buy it off the shelf, build it. Simple. Go build it. If you’re trying to implement a system for ordering, means you want to order something. Order gets sent to the vendor. Vendor takes the order, fulfills the order. The order gets shipped to your fulfillment center or your distribution center. Then, at the fulfillment center or distribution center, they do pick and pack, and they send it to the different stores. The store receives it and sells it to the customer. All these processes, you go and buy product from off-the-shelf because those processes, you’re not going to get any competitive advantage on it. You may get it by how fast they can do it, but system-wise, it’s the same process. It doesn’t matter who you are, which company you’re using. They’re going to use the same thing. Again, in that case, you go and buy it. Again, this is where you leverage your partnership to buy something. Maybe in this case, you leverage a partnership where you say that you’re going to have exclusive partnership for this feature that you’re buying, that your direct competitors cannot have for X number of years. Again, change is hard, but we got this.

Another great quote from one of my favorite books, “Start with Why,” always start with why. Without a why, you have to resort to manipulation to get people to engage with your product or services, which only leads to short term results. Leaders who start with why get people to follow them willingly instead. Important. I’ve seen organizations where they have gone and hired a guy from FAANG, who only had 18 months of experience doing technical sales job, technical director of selling something. They hired him as an executive at this company. His big thing is he knows everybody by first name. Great. Doesn’t understand technology at all. He has some ideas that he wants to enforce it on you without telling you the reason behind it. Guess what’s happening with that company? Majority of the good folks who used to work there are no longer there. The people who are still there, they are there because, multiple reasons. One reason could be, they’re looking for other jobs, to get out of there. Or, they’re just there because they don’t know what’s better outside. The point I’m trying to make is, leaders who start with a why get people to follow them willingly. They’re not there because other folks don’t have anything else to do, so they’re stuck with that in that organization. It’s very important.

Listen, Influence, and Coach

Here comes my nerdy slide, what I call, listen, influence, and coach. I’m sure you have heard of the term DevOps. Coach your leaders and team that DevOps is not moving all your development and support teams under one leader and saying, “We are DevOps.” That’s not what DevOps is. One of my biggest advocates, a former CIO at T-Mobile, Gary King, used to say this about what DevOps is, “You build it, you own it.” What that means is, as a team, there’s no production support or development team, as a feature team, or as a team, you are accountable for end-to-end. It means, as a team, you’re responsible for how the UX/UI looks like. You are responsible to develop it. You are responsible to support it. You are responsible for security. You are responsible for end-to-end. You’re accountable. If you take shortcuts, this is what’s going to happen, you will get called at 2 a.m. in the morning. Your MTTR will be completely out of control, because you need to own it. That’s what DevOps is. That’s what the good organizations do, complete DevOps accountability.

In my previous section, we talked about flexible architecture. This is what that means to me and why it’s important. Break systems into manageable components, so use microservices, containers. Do things in smaller chunks, so you can test it easily. It’s low risk. You can deploy it in the middle of the day. If it doesn’t work, if you have a green-blue deployment, you flip it back, and you’re back to normal. Do everything small, it’s lower risk. This is a true example. At one of my companies, before the digital transformation journey began, we were doing monthly and quarterly releases, for all our digital products. Every month or every quarter, whenever we were pushing any new releases or new code in production, we were taking 12-plus hours of downtime, with maintenance pages on our site, and on our mobile app. Maintenance pages, 12 hours of downtime for the digital product, while we are doing the code changes. By following the above two methods, and with a shifting of mindset, with lots of hard work, we went to do multiple releases a day with zero downtime. Multiple releases a day, in the middle of the day, with zero downtime.

How did we do it? We invested in CI, CD, CT, in addition to obviously breaking the system into manageable components, mindset shift, lots of hard work. We also enabled CI, CD, CT mindset. What that means is, make code deployment boring and hands off. Why? It will help with your MTTR. What is MTTR? Mean time to recovery or mean time to restore. If you do things in smaller chunks, or smaller code, and you can do it quickly, test and deploy, and it is low risk. Maybe you implemented a feature in the middle of the day, and something went wrong, because we all test our code. Something goes wrong. You know you made the change. You can simply go and say, when did this problem start? Five minutes ago. What happened five minutes ago? This code got deployed. Use your green-blue deployment, flip it back. Your MTTR improved. At this company, our MTTR used to be a couple of hours for basic digital product problems. Just by doing this simple stuff, our MTTR went from hours to minutes.

Once again, you can’t improve what you can’t measure. Influence a culture where no feature goes live in production, without some telemetry. Then, obviously, use the data to make decisions. By design, I said some telemetry. You can’t build a robust telemetry for every feature that you’re building, but have a basic telemetry, basic KPIs. What is the performance of the feature that you’re building? Has the performance improved or decreased? If you’re building a mobile app, what is your DAU, daily active users? What feature you’re implementing. How is that working? What is your bounce rate? Simple thing. You’ve got to implement some telemetry for the feature that you’re enabling. As far as using data to make decisions, again, this is a fact. We use data to make decisions, and we got rid of what we call, eyes on glass team. These were the folks who used to sit in a room with four or five TVs, and they used to watch metrics on the TVs, eyes on glass. Depending on if certain metrics hit certain thresholds, they used to log in and run a script. For example, if a server is going bad, they will log in and remove the server from the rotation. Just by enabling a data-driven decision and by automating those with scripting, we were able to save $5 million to $6 million in OpEx in one quarter. Huge savings. If you go and tell your CIO, or CTO, or a CDO, that you saved $5 million to $6 million in OpEx in one quarter, he or she may give you a hug. He may just take a picture with you, with his or her arms around you that you can post on LinkedIn, or Twitter, or whatever the social media you use, and get some likes, whatever works. The point is, there’s easy ways to do these things. You can’t improve what you don’t measure.

Communicate and Celebrate

Continuation from my telemetry discussion before, enable self-healing systems for critical flows. Practice agility. You don’t have to know all, seek out partnership as a differentiator. What do I mean there? For example, if you want to enable CI/CD in your organization, and you don’t have the expertise. Go find a vendor who has done this, who can come in and give you a framework on how to enable CI/CD. The reason I did not say CT, continuous testing, you cannot get a vendor to come and help you build a continuous testing framework. Those tests are specific to your product, your company, your areas of expertise, your system. You cannot take from someone else’s continuous testing script and say, I’m going to use it here. That will not work. Use the partnership to build your CI/CD framework, as just one example. That’s the idea.

Over-communicate, and communicate often. You can do this through townhalls, roadshow, a sprint demo. I’ve been with this new company, Couche-Tard, for about 11 months, and you have no idea how many times I’ve spent on traveling, and talking to, all the way from C-suite, to wonderful folks at the store. Just to tell them the why we’re doing what we’re doing, how that’s going to help them, from a C-suite perspective, how that’s going to help their EBITDA. From wonderful folks, store perspective, how that’s going to make their life easier. Because as you and I know, that folks at the store have so much going on that if you can take one thing away from them, it just makes their life easier. Communicate. Over-communicate through multiple means. Obviously, you can also do moderated testing and unmoderated testing.

Lastly, I cannot emphasize this enough, celebrate every success, it doesn’t matter how small. For example, after every sprint, take your team out for drinks, to whatever they drink. If you see that one of your team members is working very hard, or working off-hours, why he or she is working off-hours, that’s up to you. Because if you have done your job correctly, there should be work-life balance. For some reason, if that happens, get him or her a gift card to a favorite restaurant that they can go with a significant other or with their family. If this person is in sports, like I am, give them tickets to a football game, basketball game, or tennis, or golf, whatever works. The point I’m trying to make is that, recognize your folks when they’re working hard. Celebrate every success, it doesn’t matter how big or how small. Yes, you do a demo after every sprint, even for backend without fancy UX/UI interfaces. Two things, this brings transparency to your stakeholder, number one. Number two is, you have no idea how many times your stakeholders want to know how soon the data will be available, or how soon the data gets updated. If you have just backend, you don’t have UX/UI fancy interfaces, run a script, and then show them, I just ran a script and within a second the table got updated. They will appreciate a lot.

Finally, give your time to innovate. You can do this multiple means. This is what I have done. Take 10% of your story points in every sprint and allocate that time for either innovation, or for tech debt. That’s one way of doing it. Other ways, maybe doing monthly or quarterly Kaizen events. This is where what you say is every quarter, every month, you give four days break to those teams, so they’re not working on their core product. The idea behind those four days, is that three days, they go and work with either cross-functional team within their own team, and come up with any creative idea to make their life easier, to make their customer’s life easier. The idea could be as simple as that, that right now, the change management process in order to push a code in, it takes five different steps. Partner with change management team and come up with one step, it could be anything. The idea is that, out of the four days, they use those three days, and the fourth day they come back and provide a presentation as to what that idea is, and how that idea is going to help their team, them, or the customer. That’s one way of doing it. Other example could be using your mobile app to maybe scan a prescription on your prescription bottle, instead of people entering the prescription by hand, manually. Maybe use the camera on the back of your phone, and scan it, and scan gets sent, or prescription gets scanned and it gets sent automatically to your pharmacy for reference. It could be anything. When you’re innovating, what usually doesn’t work is building an innovation team to innovate. Great organizations don’t depend on a small number of people, teams to come up with innovation. Instead, they create a culture in which every employee is encouraged and empowered to innovate.

If you go and look at my LinkedIn, you will see there’s a company, my title was a director of digital development and innovation. We got some conflict there, because my other team who were doing development work, their comment was, why are these teams so important that they are in the innovation team? You know what we did? We started rotating people. There was no one team who’s responsible in a way. The idea was that anybody, we all are innovators, we all should innovate.

Case Study – Global Mobile App Program

Here’s the case study from my team’s current effort toward digital transformation. Team did research, learned about our customers, and created personas. Explain the where, what, and why now. Align on the framework with very clear North Stars what our platform objectives are? What key expenses they’re going to deliver, and when, and how we’re going to prioritize it? Then we used the WSJF model to prioritize those features. If you’re trying to take a screenshot of personas and the framework, obviously you will see personas are dummy personas, because we really can’t share our personas with you, because we don’t want to share it with our direct competitors. Obviously, we don’t want to share what the North Stars are. We don’t want to share what other key experiences we are building, and it’s coming. That’s the reason why you see some black boxes, and also see the personas as dummies.

We communicated often at every level of the arc. Remember I told you that I have meetings all the way from C-suite to one of the people at the store. Again, we communicate often at every level of the arc. We enable telemetry to observe and measure and use data to make priority decisions. Using the 80/20 rule, we deployed the early access version of our mobile app, I think, in the first week of August. If you really look at the app that we enabled on August 1st to now, it has gone through multiple iterations. That was the idea. We didn’t want to wait for perfection to put the app out. We wanted to get the app out in front of our customer and get their feedback, and implement those feedback. That’s where the 80/20 rule comes in. We have added so many features that customers were asking for. For example, they wanted to see the fuel prices on the homepage, we added it. We could have spent six more months making our app perfect. That’s too late. Always use 80/20 rule, and then listen to your customer to iterate on your product. Where we are now, we are on track to build a Circle K in a Pocket with these features. Finally, our goal is to have a team win the Webby Awards in 2024. As you can see, we have feature 2, 3, 4. What we’re building is very cool.

Key Takeaways to Digital Transformation

The key takeaways are people, process, partnerships, and technologies. Digital transformation is not about new, fancy, cool technologies, or tools. It’s a mindset shift, and requires awareness and understanding of your customer needs. This is what we say in my team, “This is not the end, it’s only the beginning.” Partnerships are very important. You don’t have to know everything. You don’t have to be know-all. There are some stuff that you can partner with your other vendors who can help you with it because they have done it. Don’t start from scratch. Those four things are very important.

Questions and Answers

Reisz: Focus on your core competencies. If you can outsource something that isn’t a core competency, a core differentiator, why not?

One of the challenges I’ve faced with some clients with transformation, is that mindset shift that you talked about at the very beginning. I get this, how long is it going to take question all the time. Despite even saying, this is a mindset shift, it’s not about checking four boxes to get someplace a month later, or a quarter later, or six months later, a year later, when is this going to be done? How do you deal with that? How do you deal with and really drive home, particularly at senior leadership levels, that what you’re embarking on is transformation and it’s a mindset shift, not a checklist of things to lift and shift something to cloud, for example?

Iqbal: I think that’s where I gave an example about lift and shift, because there was an organization that I worked with, and our executives, the big thing was, we want to get into a cloud, because that’s a new thing. Just take everything from here, point A to point B, and say we are done. That’s not how it works. What you do is, you have to show empathy. You have to understand the why behind it, from the executives, like, why do they want to do certain things so fast? Then understand their point of view. Then show them, there’s a better way of doing it. Yes, I can do lift and shift for you right now, but long term, it’s going to cost you more, because we want to do it the right way. Executives, whenever the cost comes in, or EBITDA comes in, that gets the point across.

That’s number one. Number two is, it’s possible sometimes that you maybe do something hybrid, where you do some lift and shift, but still have a plan to do it the correct way. Again, open dialogue, talking to them, understanding their reasoning. Then understanding the outcomes they are looking for, and coaching them, mentoring them to say, this is how we can do it. At the end, finally, they write you a check, they are the decision makers. Sometimes you have to do it just to get what they want us to do, because there’s a business reason for it. They understand that.

Reisz: How do you get people on board? You talked about starting with why. You talked about being empathetic. Any strategies on really getting people on board and overcoming that resistance to like, we’ve always done it this way. How do we really get them on board to do a digital transformation?

Iqbal: Relationship building. You have no idea how much time I’ve spent on what we call coffee breaks or coffee talk. Take people out. Before you want their help, like your business partner, take them out to a coffee. In that coffee, you’re not talking about what you’re trying to do, get to know them personally. Know who their kids are, what they’re interested in, what sports they like, things like that. When you get to the point where you need their help to transform, or to change the mindset, they know that there’s nothing in for me or you, it’s what’s in it for them. Relationship building, spending the time with them before you need their help, things like that. Those are the core principles of build relationships, when you need help, they’re there to help you.

Reisz: When you were talking about the HIP, innovation and planning and getting tech debt, and you talked about doing hackathons. I think that’s another great way of building relationships between teams, just like you get into your silo working in your team. These hackathons let you break down some of these things and work across teams. Work together on maybe a data team that isn’t maybe your core area, for example, and really see how you can bring some of those in. I think those are other great ways to tie in what you’re saying.

Iqbal: We just don’t do Kaizen events within my team. Like you said, that kills the purpose. We will bring legal team, we will bring data team, we will bring change management team, and we will bring product team to say, this is what we want to do. What can we do? How can we partner together to do something like that? Kaizen works but you will not get as much benefit if you just do it within your own siloed team.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Transcript

Cole: I’m here to talk to you about why I think everyone can be a full stack software engineer. Currently, web apps are built often with large teams of engineers, with each engineer just owning a little piece of the puzzle. I think that there’s a better model for developing modern web apps, one in which individual engineers get to own their feature, all the way from the top of the stack to the bottom. I think when you do it, this way, we can ship more product features faster, and individual engineers are able to think deeper about the product experience. When I say modern web app, what am I talking about? I’m talking about apps like these, apps like Facebook, Airbnb, Slack, Asana, Reddit. What do all of these have in common? First, they’re websites that have dynamic content. We’re no longer serving static HTML to everyone on the internet. Instead, different information is served to each user that’s pulled from some database. The app is personal and has user generated content. The second thing is that these apps, at least when they’re done well, are reactive. When a user loads the app, they’ll see the changes to the data happening in real time. You don’t have to refresh the page, but the most up to date content is pushed directly to the browser. The last thing is that these apps are all interactive. Not only can you view data, but you can add your own content, write posts, write messages. When you do that, you see your own edits update in real time. The sum total of all these properties together can make these apps when they’re done really well just feel native. Users will no longer feel like they’re on a website, but they feel like they’re having a rich native experience. This is what I want to talk about. I want to talk about how you build apps like these, and how we can design the infrastructure for these apps to enable individual software engineers to own the whole stack.

Background

Who am I? My name is Alex. I’m a software engineer at Convex. Convex is a reactive Backend as a Service. We’re helping people build their web apps on top of our serverless infrastructure, so you don’t have to manage all the infrastructure yourself. We’ve been doing a lot of thinking about what are the right ways to build web apps today. Before this, I worked at Asana. I was leading the client infrastructure team. This was a team that was building out the reactive web framework that Asana uses internally. I also did a lot of thinking there about, what are the right abstractions to give product engineers? How can we put product engineers into the pit of success? All of this combined means I care deeply about how we build modern reactive web apps. I want to tell you a bunch about my thinking.

Web App Architecture

First up, I want to talk about the architecture that most apps are using today. What is happening behind the scenes in these large web apps? What problems do these architectures hit? Let’s start by talking through a example web app. What do we need if we want to get our app off the ground and serve to users? We’re going to need a couple things. We’re going to need to build a frontend, probably we’ll build it in React. We’ll write some React components and put together the UI that we really want to deliver to our users. That frontend is going to need to go and talk to some backend. We’re going to need a way to run server-side business logic. Probably, we’re going to define some endpoints or GraphQL schema and GraphQL resolvers to load and mutate data. The dotted line in this diagram represents the boundary between the client and the server. The frontend is going to make some requests to the backend. Then on top of that, we need some way to permanently store data. We’re going to need some type of database, perhaps MySQL, or MongoDB. That’s going to store data based on some schema for our app.

To start, this is it. Many apps will launch with a three-level architecture like this and get right off the ground running. Once our app is wildly successful, we’re going to hit some limitations here. I think one of the first limitations we’re going to hit is that an individual backend might not be powerful enough to serve all of our users. We could have problems like the backend is going down because there’s just too many requests, or every time we rewrite the code in the backend, we have to swap it out for a new one and there’s downtime. Likely, the first step as we’re growing our application is that we’re going to need to expand the backend to no longer be a single service. Instead, we’ll run multiple copies of the backend and have a load balancer in front of them. This will give us some redundancy, so if one backend goes down, we’ll be able to handle that fine. It will also help us because now when we redeploy code, we can have our load balancer talk to the new backends instead of the old ones, and do seamless transitions. Yes, Asana started out with an architecture very much like this.

Are we done? Are we ready to check off and just run our app and keep it in production like this? I think not. I think as our user base grows, we’re not at the end of our scaling woes. I think the next part of our system diagram that may have issues is the database. Here, we’re running a single database, which once again means that it can be a single point of failure. One, if our user base grows enough, we’re no longer going to be able to handle our traffic in one database. If we don’t have a database, we don’t have an app. I think the next step in our scaling is that we’re going to want to shard the database. Instead of running one big database, we’re going to probably want to split our customer’s content into separate shards where different shards live on different databases. This will let us horizontally scale the database layer and grow to more numbers of users. It also means that an outage on one database won’t affect everybody. Also, surprisingly, Asana started out with a single database and reached those limits. As anyone who’s done sharding knows, it’s no easy task. When you’re doing sharding, you’re going to have to break up your work that maybe cross multiple different parts of your data model, into work of individual transactions on databases. You’re going to need to only be able to do a transaction on one database. If you want to write data to multiple databases, you’re going to have to think through the consistency of it yourself. That’s fine. We’re a big web app. We have a big team. We’re going to have some people who have thought hard and long about MySQL, and the right way to shard, and they’re going to split up our data into multiple databases.

What’s next? Are our scaling woes and our performance problems over? Once again, I think it just keeps getting more complicated. Next up, I think we’re probably going to need a way to improve performance beyond the database. For many apps, loading all of your data from a single database or a set of databases is fine. It’s also increasingly popular to have a caching tier as well. Here, we’ll have some cache nodes that are storing in-memory, a lot of the data from the database. These might be services like MySQL, or Redis, and instead of the backend, loading data straight from the database. At least for some kinds of content, it can go to the cache first, see if the data is in the cache, and then follow up and go to the database. If any of you have experience with caching, you will know that I just brushed under the rug a tremendous amount of complexity. As soon as you add a caching tier, now we’re going to have to make sure that the data in the cache actually matches the data in the database. It is extremely easy to end up with cache inconsistencies where some user edits data in the cache, but fails to write to the database, or vice versa, where they write to the database, but don’t update the cache. These might seem like small problems. The correct data is still saved in the DB, what’s the issue? When the users are showing up on your site, what they’re going to see is the information in the cache. If it differs from the database, they’re going to believe that their content was lost or corrupted. Likely building out this infrastructure, we’re now going to need more engineers with more expertise to make sure that the caching layer and the database stay in sync.

We did that. We’ve built the cache. Are we done? Are we ready to launch our web app and scale up to the entire user base? It keeps getting worse. I think the next problem we may run into is actually a product one, of, I said we were building these really interesting reactive, interactive apps, but the architecture diagram I’ve drawn here is really only about loading data and writing it. How are users going to see content when it changes? We’re going to need to make it reactive. The standard way to make it reactive would be to change our frontend to no longer use HTTP to request its data, but instead have some long-lived WebSocket connection to the backend. That’s the double ended arrow. Using a WebSocket means that we can still load data on the frontend by requesting it from our backend, but also, it’ll keep a connection to the backend open, so the backend can push data all the way to the frontend. How is the backend going to know when to push what data? This will require yet another new piece of infrastructure. A common choice is to use a Pub/Sub service. The idea behind this is that the backends will be able to publish topics to the Pub/Sub service whenever they edit any information. They’ll subscribe to the information that their clients currently care about. The Pub/Sub service will act as a Message Broker, letting backends know when information changes. Asana also did exactly this. Asana had an in-house Pub/Sub system they built themselves, and broke up the data model into these fine-grained Pub/Sub topics, and used those to push around information, so that anytime you’re viewing content in the app, you would see it change in real time.

Once again, there was a lot of complexity here. There was a lot of complexity in getting in the correctness right, of how do you correctly publish and write to the database at the same time? You can’t. There’s complexity in making the frontend be able to understand the messages about changes to information. We’re going to need some way for the frontend to have some local client store, and store all of this data and update it as it changes. We’ve already scaled up our team. We’re going to have some set of people that are working just on reactivity in Pub/Sub. About now is when I run out of space on the screen, but that doesn’t mean that the complexity stops growing. I think in many modern web apps, there’s actually a lot more boxes in this diagram. Some other common choices are that if your product someday needs to have full text search, you want the ability for users to search for messages by the text in them, your existing database might not be able to handle that. You add in a whole nother database. We can start running something like Elasticsearch to fill those queries.

At some point, we might want to be able to do things like send emails in the background. If we want to have background jobs, we’re going to need some job queue where we can schedule jobs to happen, and workers that actually do the work. We’re probably, as the site scales up, going to need to have analytics. People are going to want to know what users are doing on the site. How many users we have? We’ll also need to add in a data warehouse. It just keeps going. I think yes, basically, as I’ve described here, this is the state of the art for modern web development. You’re combining together a bunch of different services. It’s your responsibility to wire them all up in the right way and keep them consistent. It works. I think almost every logo I have written on the first slide was built in this way.

Who’s Going to Manage This Complex App?

There’s also some downsides. I think one of the big questions comes down to the people involved. How many people are we going to need? How are they going to be divided up into teams? For this imaginary app, we’re probably going to need a frontend team. We’re going to need some people who know how to write really good JavaScript and TypeScript, CSS and HTML, because we’re building a site for the web. There’s a bunch of specific technologies that this team is going to have to be experts in. They’re going to need to be understanding React, GraphQL. They’re going to need to know how browsers work, and be thinking through the UI. On top of this, we’re probably going to need a separate backend team. These are people that are going to be writing our backend business logic. Probably, we picked a backend language like Java, Python, or Ruby. We’re going to need to be doing SQL queries from the backend in order to load our data. These engineers are going to have to think really hard about performance and security. We have a frontend team, a team that writes the backend business logic. What about all the other boxes in this diagram? We’re also going to need to have another team, some SRE, DBA, or infrastructure team. This team would think a lot about scalability, reliability, correctness, and performance, and probably be doing a lot of writing configuration scripts, SQL, to keep the site running and everything correct and performant. This is a lot. I had a diagram that filled the whole slides of the architecture. We have three different teams here. We know we need all of that before I’ve even told you what app we’re actually building. Pretty wild.

Web App Product Development

Just to round this out, let’s think about what product development looks like in this model. Let’s imagine now that we actually want to go and add a new feature to our app, given this architecture and these teams. As a toy feature to talk about adding, let’s imagine that we’re building a chat app like Slack. We want to add channels to the app for the first time. We already have a single channel chat app, but now we want to go and add the ability for users to have custom channels, send messages in those channels, see the full list of channels, all that good stuff. What do we need to do to add channels? First, we’re going to need to think at the bottom of the stack. At the database layer, we need some way to define a SQL schema and define what our data model is. This is probably going to be a conversation between the backend team who is thinking about what kind of endpoints we need to write, and the infrastructure team who is thinking about scalability and performance. They’re going to agree on a SQL schema. Once they do that, we’re going to need to actually go update our database to have the schema. Maybe the infrastructure team is going to go add the schema, whatever appropriate indices we think we’ll need, and also, generally scale up the services to support this new feature.

We have the schema, what’s next? Next up, we’re going to need the backend and frontend teams to talk to each other to define the API of the endpoints. If we’re building a chat app, we probably need a way to load the list of channels. We’re going to need a way to load messages that are in a specific channel. We’re going to need to be able to create channels, delete channels, rename channels. We’re going to need to make sure that the frontend team is getting all of their needs met by the endpoints, but also that they can be implemented by the backend team. Often, I’ve seen teams that will jump to GraphQL to solve this. Because this conversation is so difficult, it’s often nice to have a rigid structured language in order to guide the conversation and write down the conclusions.

Backend and frontend teams, we’ve defined the API. Finally, the backend team can go and actually build the endpoints. They’ll implement this API and use the SQL schema that the infrastructure team set up for them. Finally, only then can we actually go and build the components and actually build the UI. Now the frontend team can write the components, and we have built our new feature, end-to-end. How do we feel about this process? In total, we had over six different services involved. There were five steps. We had at least three teams. I think realistically, even for a small feature like this, it’s going to take weeks. There’s just too many moving parts involved, too many different people. The work of developing the feature has been split up between totally different teams, so that no team is thinking about this feature, end-to-end. Everybody is focusing on their part and throwing a bit of work over the wall.

Serverless Architecture

Can we do better? What does a better model look like? What does a world look like in which people could actually own their features, end-to-end? To say the negative version here, in this existing model, how could anyone be a full stack engineer? It seems completely infeasible for a single engineer to be thinking about or owning this much infrastructure? It seems impossible. How could we do it? What would it look like? I think the thing I want to talk about next is, what a serverless architecture would look like for building a complex web app like this. How does serverless change things? How does it change the teams that are building the apps? Before we talk about what architecture we’re actually going to use, I think we should come back to this complicated one that we had before, and focus in on the question of, what part is the app? I drew all of these boxes before I even told you what app we’re building. What parts of these boxes actually have to do with the product features we’re building? I think there’s a couple of bits here. On the frontend side, we’re going to have different React components depending on what app we’re building. The React components are specific to the user experience we want to give.

Similarly, on the backend, there’s bits of business logic. We talked about the fact that every new product feature is going to need new endpoints or adjustments to the endpoints. When you condense down what is an endpoint, all it really is, is a function. We need a function that’s going to be taking in an HTTP request and returning some data to the frontend. There’s some functions on the backend. Then the last piece that changes and is part of our app is the database schema. Every app needs to store information in the database, but the schema they use to store it depends on your data model in particular. I claim that this is really it. When I think about what is the app, there’s the React components, there’s functions in the backend, and there’s a database schema. Everything else in this diagram, that’s just scaffolding to get these three things in place. If we want to remove as much unnecessary complexity as possible, where do we end up? If we want to empower engineers to edit the whole app, how do we do it? I think we need to do a few things. We need to remove all this excess complexity. We want to focus in on just those three things, your React components, your functions, and your schema, and manage everything else centrally. The second thing is that if we want engineers to actually be able to edit the whole app themselves, we need to write all of these pieces in the same language. Given the realities of web development today, I think we have to pick JavaScript or TypeScript, because that’s the one that can run in the browser. Then once we’ve done this, profit. If we can remove all the complexity and write everything in the same language, I think we’re going to be in a really good place. Let me convince you of this.

In this serverless architecture, these are the only things we need. We need React components, some way to build the UI. We need backend serverless functions, some way to have backend business logic and run code on the server. We need a schema. We need to describe how we want to save our data in a database. Unlike the previous diagrams, this is it. I’m not going to be pulling out any more complexity here because there isn’t any more. I think these three ingredients really give us everything we need to build the app.

Serverless Responsibilities

When we’ve done this, let’s break down what the responsibilities are. If you’re using a serverless architecture like this, you have to manage just those three things. You’ll have to write UI components. You’ll have to write serverless functions. You’ll have to define a schema. Where did all of the other parts go? How are those getting taken care of? If you’re using a serverless provider, you’re giving them the responsibility for handling the scalability, correctness, caching, and performance, reactivity, backups, availability hosting, the whole list. I think we didn’t do anything totally revolutionary here. I just took the responsibilities that used to be spread across a large engineering team, and offloaded them into a serverless hosting provider. Yes, and having personally worked on a large engineering team building Asana, I can tell you that a large fraction of engineers were actually focused on all of these problems, and not the UI components, the functions, and the schema. By giving the provider all of these responsibilities, it will let you focus in on building the parts of the app that actually affect your user experience.

Serverless Product Development

That sounds good in theory, but what does product development actually look like in this serverless environment? What I want to do is walk through the same example we did before. I want to just show you how that would work if you’re using Convex. I think a lot of the same ideas apply to many other serverless providers. This is the one that I know well. When you’re using Convex, you write your schema in TypeScript. Before you added messages to your chat app, your schema might look like this. Here, this is a TypeScript file. We’re importing some helpers, defineSchema, defineTable, and s. We’re defining a schema that just has a single table, messages. Messages are just objects that have two properties on them, author and body, and both of them are string. A very minimal chat app where people can post messages and say who posted them.

If we now want to expand this into a chat app that has channels, we’re just going to go ahead and add channels to our schema. Here, I’ve updated the schema. Now there’s another table called channels. Each channel is just an object that has a string name. Then we need to connect the messages to the channel somehow. In Convex, the way you can do that is by referencing the ID of the objects in the other table. Here, now messages have a channel property, and that’s just the ID of a channel. This is how we handle foreign key references. To define the schema, took 30 seconds. What’s next? We need to define the backend functions. Once again, in Convex, this is all just written in TypeScript. This is an example of the kinds of functions you might need to build this multi-channel chat app. The first function would live in a file like listChannels.js, or listChannels.ts. It’s using query here, which is saying that this is a Convex query function. In Convex, query functions let you load data, and they’re automatically reactive. Whenever you load a query function, Convex will also push to you a new version of the data whenever the underlying data changes.

In this case, what do we want to do? We want to go to the database. We’ll query the channels table, and just collect all the channels that we find. That way, we can list all of the channels in our little Slack channels picker. I should say though that in a Convex query function, you can write arbitrary TypeScript, and it’ll still be reactive. If we wanted to take the length of this list and list how many channels there are, we could get a live updating number of the number of channels in the app. We don’t just want to list the channels, we also need a way to add new channels. We can define that using this Convex mutation in addChannel file. Here, this is a mutation that takes in the name, string, and then inserts a new document into the channels table with that name. Nothing revolutionary here. I think the cool part is that the same engineer who went and wrote the schema, could easily hop over here and start writing the functions. They’re just in the same code base, TypeScript code: nothing magical, nothing special.

Then the last piece is that we actually need to use these functions to build components and add on that new UI for our new user experience. In this example, we’ll probably want to make a new React component called channels list. What does that do? We need to load the channels if we want to list them. Convex gives you a useQuery hook. UseQuery takes in the name of a query function, and just gives you a reactive version of the result. This is a live updating set of channels. Then based on those, we’re going to render some UI. Maybe we map through all the channels. For each channel, we render a link that lets you load the messages in that channel. That’s it. You can load data from queries on the frontend. You can call mutations. That gives you all of the tools you need to build any interactive experience.

I think when we’ve done this, it is both completely obvious and also somewhat revolutionary. We’ve taken a process that was going to take weeks for 3 different teams to complete, and I just described how to do it in 10 minutes. By using the same language and the same abstractions at every layer of the stack, it’s now realistic for individual engineers to understand all of this and own their feature, end-to-end. Instead of having people split up on what part of the stack they’re working on, you can now have teams that are just focused on their parts of the data model and their features, and can think through how to build those features, end-to-end.

Serverless Bonuses

On top of that, I think there are some things that you get with serverless that are actually just hard to build in traditional architectures. Let me give you my two examples of what you get for free by using serverless that may have never been able to be built using a traditional model. The first one is reactivity by default. When I say that, what do I mean? Often, in an app, you’re starting in the way that I did in my example, where you start by calling endpoints and loading nonreactive data. Then adding on a Pub/Sub system, which will give you some amount of reactivity, but perhaps only to the things that you actually manually built it for. It’s very common to have apps where the chat portion of the app is reactive, but the other views are not because that would be extra infrastructure and extra engineering complexity. In Convex though, you actually get this for free. Any time that you load a query on the frontend, Convex pushes you updates to that query whenever the data changes. An example of the experience I mean, is look at these two windows. There’s one here that’s creating a channel, and then one that is viewing the channels list. In Slack, for example, when you go and hit new channel and click the Create button, the new channel pops up in the channels list immediately. I think this is a detail that can take an enormous amount of work in a traditional architecture. If you’re using a centralized system like Convex that understands the data that query functions load, then it can push newer updates to those query functions whenever the underlying data changes.

The second freebie that you get in this system is end-to-end type safety. Because we’ve written all of our code in TypeScript on every layer of the stack, we can give you really good precise generated types. What do I mean by this? Here, I’m inside of a React component, channels list, and I’m calling the useQuery hook in Convex. UseQuery now understands what query functions we’ve defined, and autocompletes them automatically. Here, you can see that there’s a listChannels query function, and a listMessages query function in our code base. Often, this thing can be built in other frameworks, but requires complex code generation to take your SQL schema and turn it into TypeScript, or take your GraphQL schema and build your types for your GraphQL client. In Convex, this is all piped together in end-to-end correct automatically.

Similarly, the types can actually just flow all the way from the database layer up into your UI. Our listChannels query function was loading a list of channel objects. Here, when we load those channels on the frontend, you can see that it’s just an array of documents that each have an ID, a creation time, and a name. One field that we defined, two system fields that got added, but we can see them all in our editor right here. I think this also helps engineers move faster across all layers of the stack, because they know that the types are going to guide them through the process.

Parting Thoughts

A couple conclusions and parting thoughts to walk away with. The first one is that most of the complexity in modern web apps has nothing to do with the app at all. Our standard infrastructure and pieces that we wire together actually are amazingly complex. That’s part of what necessitates these large engineering teams, where each individual engineer only owns a tiny part of the stack. Second, if we can remove this complexity, first, it obviously saves time. If there’s things that your team doesn’t need to manage, you can focus more on the other options. It also changes how you actually work. When you’re only focusing in on the parts of the app that have to do with your app, you can think about them more holistically, and own the same thing, own features end-to-end. The last thing, everyone can be a full stack engineer. Once you remove all the unnecessary complexity, it is completely feasible for engineers to work all the way from the schema layer up to the UI, and think about an entire product feature.

Questions and Answers

Dunphy: You talked about outsourcing our infra to teams who specialize in areas we would normally manage in-house. While this sounds great in theory, to me, is there actually a complexity tradeoff here when we outsource these critical tasks?

Cole: I definitely think about it as just moving around the complexity, not necessarily trading it off. There is some inherent complexity in building the infrastructure for a modern web app. It’s just a question of here’s the in-house team doing it or an external team. I also think it’s interesting to put this in the larger arc of like, how has engineering big web apps changed over time? It used to be that you would have a server sitting in your garage that you would manage yourself and buy. Now with hosted platforms, like AWS, people switch to using EC2. In addition, people are increasingly using more managed databases like RDS. I think the line about like, which parts of the infrastructure you manage, and which ones you’re paying to manage, is just continually moving up. Sooner or later, people are also not going to want to be provisioning their own backends, and that type of thing.

Dunphy: Perhaps it’s not exactly more complex, it’s just a different type of complexity.

Cole: Yes, for sure. The complexity is now moving into the realm of specialists who are building this as their business.

Dunphy: I think many people who have really not tried this architecture may have a perception that it’s not ready for large scale production applications. What is your response to this? Are there any companies you know who are using serverless architecture at scale?

Cole: Yes, for sure. I think as with any new technology, a lot of the early adopters are smaller companies who are more willing to try it out and take a risk. I think anecdotally, I’m definitely hearing about big companies that are dipping their toe in, testing the waters, using it for small features or small parts of their app. Some companies that are also just building their apps on top of it. Certainly, AWS Lambda, I think probably the biggest serverless product out there right now has a ridiculously long, impressive list of logos on their website. It seems like Zillow, Coinbase, lots of people are switching and using Lambdas to simplify their stack. I think certainly the trend is undeniable that, yes, more companies are using this in the future.

Dunphy: Is that something you would recommend to get started with serverless is just try it out in some small section of an app or some small new feature.

Cole: I think, like any new technology, you don’t want to move your entire web app onto this and assume that it will work and be fine. I think finding small ways to test it out, make sure that it works for you and your technology, I think is always a good way to get started.

Dunphy: How do you manage migrations of schema?

Cole: Obviously, this thing varies depending on which product you’re using. In the case of Convex, the schemas are actually pretty interesting, because you can use Convex either with a schema where you explicitly write out what tables you have, and what types those tables have. Then they generate TypeScript types, or even without a schema where you just put in data and pull it out and keep track of this on your own. I think Convex currently has limited ad hoc schema migration capabilities. You definitely can go and write mutations that read out your data in one format and write it back in another. We also are planning to add more automated schema migrations, where you can write a transform from your documents from one format to another and have that run automatically.

Dunphy: How do you imagine these principles to work for teams having multiple frontends, web and mobile, or even only mobile?

Cole: I think the dream is that a lot of this just applies directly. Certainly, if you have an app that is only mobile, I still think it’s a really good model to have the same engineers building out the app as the people building out the backend, because they can think holistically about their feature. I’m also excited and interested in ways to break down the barriers between web and mobile at companies that have both. When I worked at Asana, there was actually a very hard line between the web engineers and the mobile engineers. Product features that required launching in both were these like complicated coordination game. I think with new frameworks like React Native, where you can build your mobile app in React components, just like your web app, some of these boundaries are becoming a little looser. I’m excited about ways in which the same engineers can build product in all the platforms.

Dunphy: This is what got me into the React community. I produce the conference, Reactathon. I’ve been very close to the React community for a long time. It was really the keynote in I think it was 2014 or 2015, when they introduced React Native that I was like, this is game changing. It’s proven to be. Now we have technologies like Expo, for those of you who are interested in cross platform development, I would highly encourage you to check that out. Expo is a technology where you can build for mobile across platforms and web with the same code. It’s just incredible.

Can you host Convex on Azure Serverless infra such as App Service?

Cole: No, not yet. Convex internally is running on top of AWS, but we actually manage all that for you. That’s an implementation detail that we don’t actually talk about. I think if there’s demand for more different hosting options, and that thing, certainly we’re willing to expand and be more flexible there.

Dunphy: How did quality assurance adopt this transformation to serverless architecture?

Cole: I actually don’t have that much experience with quality assurance. When I was working at Asana, the way that things mostly worked is we relied really heavily on automated tests, so that we could ensure code is working. Asana would actually release code twice a day, which is just so fast, that having like manual QA process is not really possible. In general, I don’t think switching to serverless drastically changes how your team has to do QA. If you’re using automated tests, you can certainly write automated tests against serverless infrastructure, just like you could with your traditional infrastructure. If you want to do a manual QA process, I think that’s also just as easy to do as ever. Maybe in some ways, even easier if you can spin up a backend without having to provision servers and have some staging environment that your QA people use, because you don’t actually have to manage the servers. Having a second deployment of Convex out there to test against is super easy.

Dunphy: Does this model imply your product will be a monolith? Do all teams need to work in the same repo and have the same SDLC, software development life cycle?

Cole: Certainly, my hot take is that I actually love monoliths. I think that having everything in the same repo makes it easier for developers to cross boundaries and jump into parts of the code that they don’t normally work on. I think, yes, having a single software development life cycle is a often pretty simple model for most teams, unless you’re getting up to some huge scale and really want to separate deployments into more granular units. That being said, if you wanted to split things up more, that’s also an option. You certainly could use serverless and have a separate repo for your backend and a separate repo for your frontend. I think getting more granular than that, though, is actually not very common. In a traditional architecture, you may have many microservices and want to deploy these all separately. Now that you’re not really managing deployment at all, it’s being managed by your serverless hosting provider. I think the benefit of splitting up these microservices into tiny little pieces, at least in my mind, no longer makes sense, because you’re not even managing deployments. If you’re using Netlify or Vercel and deploying every time a new commit is pushed, I don’t think that this sharding up into pieces is really necessary anymore.

Dunphy: How would you recommend going with React Native in brownfield, a hybrid, or a rewrite?

Cole: I think my understanding right now is it’s an emerging technology. Plenty of people are still building apps in a more traditional way, using Swift or Java to build native iOS and Android things. I would consider React Native if you have a team that is already used to writing React components. I think that makes it much easier to start an iOS project. I don’t know that much, though, about the integration between React Native and traditional apps. I think if you’re in a brownfield environment where you’re trying to transition your app to a new technology, I would just make sure that there’s a really good incremental migration plan. In general, I’m always scared about do it all at once rewrites where you stop the world and rewrite your app in a new framework. At Asana, we were always very careful to make sure our rewrites were incremental so we could ship pieces as we went. That made it possible to make some really big changes to our infrastructure.

Dunphy: Why did you leave Asana for Convex? What excites you about Convex, that perhaps you didn’t get while working at Asana?

Cole: At Asana, I worked a lot on the reactive data loading framework that Asana built in-house called Luna. I think it was cool to see how this supercharged our product engineers and enabled them to build new features really rapidly. I think part of my excitement in coming into Convex is getting to work on the same thing, but building it for the rest of the community. Because I think that there were a lot of cool things going on at Asana that, yes, I’m excited to bring to the rest of engineers.

Dunphy: Why were you so excited to join Convex?

Cole: I think they were thinking about a lot of the same kinds of problems in good ways. Also, it’s fun to join a small team with a lot of good people.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

This week’s roundup for April 3rd, 2023 includes the most recent news and information from the fields of data science, machine learning, and artificial intelligence. This week, OpenAI, Microsoft, Meta, and Bloomberg are just a few of the leading competitors in the market whose new breakthroughs and innovations are the focus of our attention.

Here are the most recent developments in natural language processing (NLP) models, new developer tools for AI, ethical AI practices, and other subjects.

OpenAI

OpenAI recently announced GPT-4, the next generation of their GPT family of large language models (LLM). GPT-4 can accept both text and image inputs and outperforms state-of-the-art systems on several natural language processing (NLP) benchmarks. The model also scored in the 90th percentile on a simulated bar exam.

Also, OpenAI announced their approach to AI safety, by improving AI systems’ ability to learn from human feedback and to assist humans at evaluating AI. The goal is to build a sufficiently aligned AI system that can help solve all other alignment problems.

Microsoft

Microsoft has open sourced Semantic Kernel (SK), a lightweight SDK enabling the integration of large language models (LLMs) with conventional programs which can leverage prompt templating, vectorized memory, intelligent planning, and other capabilities.

Also, Microsoft Researchers Introduce TaskMatrix.AI. A New AI Ecosystem that Connects Foundation Models with Millions of APIs for Task Completion. The concept involves integrating foundation models with millions of existing models and system APIs, resulting in a super-AI that can perform various digital and physical tasks. While AI models and systems are currently designed to address specific domains effectively, the diversity in their implementations and working mechanisms can make it challenging for foundation models to access them. This new ecosystem aims to overcome these obstacles by providing a unified framework for connecting these AI models and systems.

Meta

Meta just released their Segment Anything Model. This new model allows AI to extract objects within images or videos with a single click. It utilizes advanced computer vision technology, which enables computers to analyze and understand visual information- such as images or videos, similar to how humans perceive and interpret what they see.

Bloomberg

Researchers from Bloomberg and John Hopkins University train BloombergGPT, a language model with 50 billion parameters that serve a variety of financial sector operations. They adopt a hybrid approach rather than creating a tiny or general-purpose LLM solely based on domain-specific data. Standard LLM standards, open financial benchmarks, and proprietary benchmarks to Bloomberg are used to evaluate the model and ensure it functions as anticipated.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Liu: I live in the beautiful city of San Francisco. One thing to know about the city is it’s very hilly. Even after three years of living in the city, I still run into this issue where every time I’m trying to get from point A to point B in the city, whether it’s for dinner or for a walk, I’ll look at Google Maps and be like, that looks easy. When I actually get on my way, at some point, I will realize that up ahead is a hill with a non-trivial incline. That happens a lot in SF because it’s hilly in so many places. When I think about it, this uphill journey resembles Airbnb’s very own journey to service oriented architecture. In a sense that we started out on this flat and straightforward path of migrating to SOA, then realized that there’s a surprisingly steep and interesting learning curve beyond that. I will share with you four key lessons that we have learned along the way.

Background

My name is Selina. I’m a software engineer at Airbnb.

Lessons from Airbnb’s Journey to SOA – Invest In Common Infra Early

Here are the four key lessons from our journey to SOA and beyond. Let’s dive straight into the first one, which is to invest in common infrastructure early in your SOA journey, because this will help to turbocharge your migration from monolith to SOA. To give you more context, let’s spend some time first on why and how we went about our migration. Back in 2008, just like most small scrappy startups, Airbnb started out with a single web application written using the Ruby on Rails framework with a model view controller paradigm. Over the years, as Airbnb expanded its global footprint product offering and engineering team, the single web app grew into a massive bloated monolith. Since it is developed using the Ruby on Rails framework, internally, we call it the monorail. As more engineers jumped onto the monorail, it was becoming slow, unstable, hard to maintain, and a single point of failure. In 2018, we launched a company-wide initiative to migrate our tech stack from this slow moving monorail, to service oriented architecture. Similar to the MVC, model view controller paradigm, we decided to decompose the monolith into, first of all, presentation services that render data in a user friendly format for frontend clients to consume. Then we also have mid-tier services that are grouped around shared business concerns and can be used in multiple contexts. Then, under those, there are data services that encapsulate multiple databases in a uniform data layer.

A Case Study – Host Reservation Details (HRD)

To make this abstract diagram a little bit more concrete, let’s use Host Reservation Details, or HRD, as a case study. Before I explain what HRD is, I want you to meet Maria. Maria is a new Airbnb host based in Colombia. She just published her listing on Airbnb last week, and today, she received her first ever booking request. When she opens her host inbox on the Airbnb website, she sees a message from the guest, Christopher, and this panel on the right here that displays key information about the trip being requested by the guest. This right panel here is the HRD or the Host Reservation Details. Taking a better look at it, we see that it has these call to action buttons that prompt the host to either accept or decline the booking request. It also pulls information from a myriad of sources in our system, including users, listings, payments, and reviews. In fact, there’s a lot more information that it offers below the fold as well.

To migrate this product feature to our SOA paradigm, we basically broke down the product logic into, first of all, a presentation service that handles view layer business logic such as formatting and translations. Then we have a few mid-tier services that handle write operations such as confirming or declining a booking request. Then we have data services down the stack that encapsulate different product entities such as reservations, users, and listings. Of course, there are many other services on each layer, and we interact with many of them every time we serve a request.

Let’s call our reservation presentation service Ramen, because, who doesn’t like Ramen? Going back to this diagram, we do interact with a lot of services every time we serve just a single product service like HRD. You can imagine that to serve all the product services we own, we need a pretty sizable number of SOA microservices to power them. What made this monumental task of migrating all the complex logic and building out our vast SOA ecosystem possible are the building blocks that our infra team provided that allowed us to build services with confidence and speed. Let me walk you through some of them.

API Framework

First, we have this in-house API framework built on the Thrift language. It is used by all Airbnb services to define clean API and to talk to each other. Let’s say that as part of our business logic, Ramen has to read data from the Tofu service. To serve that data, the Tofu engineer only has to define the endpoint in simple Thrift language, and the framework will auto-generate the endpoint logic in Tofu that handles stuff like schema validation and observability metrics. Secondly, a multi-threaded RPC client that the Ramen service can use to talk to Tofu service. It handles stuff like error propagation, circuit breaker requests, retries. This means that engineers can focus on implementing the core business logic and not spend time worrying about the plumbing details of inter-service communication. Based on the framework, we also developed productivity tools such as this API Explorer, where engineers can browse different services, figure out which endpoint to call, and even use an API playground like this one to figure out how to call the endpoints.

Powergrid

Second, we have Powergrid, which is a Java library built at Airbnb that makes it super easy to run code in parallel. Under the hood, Powergrid helps us organize our code as a directed acyclic graph, or a DAG, where each node is a function or a task. We can use it to model each of our service endpoint as a data flow with a request as the input and the response as the output of the data flow. Because it handles multi-threading and concurrency, we can easily schedule chunks of code to run in parallel. Let’s take the host sending a special offer to the guest as an example. In this write operation in Ramen service, there’s a bunch of checks and validation that have to be performed before we allow the host to send a special offer. Using Powergrid, we will basically first take the listing ID from the request body, use it to fetch information about the listing from the listing data service. Then we’ll pass the information down to a bunch of downstream services for validating, which will happen in parallel. Then after that, we will aggregate all the validation responses, make sure that we got a green light from everyone, before we write back to the special offer data service to actually send it to the guest. This Powergrid library provides a few benefits. First of all, it provides low latency for performing network IO operations concurrently, which really makes a difference when your endpoint has multiple downstream dependencies. It also offers granular metrics for each node, which helps us to pinpoint bottlenecks in the data flow. These benefits help to ensure that our code is performant, observable, and easy to reason about.

OneTouch

Third, we have OneTouch, which is a framework and a toolkit built on top of Kubernetes that allows us to manage our services transparently and to deploy to different environments efficiently. This framework has two key aspects. The first part is the principle that all service configurations should live in one place in Git. For instance, other configurations for the Ramen service will live in an infrastructure folder that lives right alongside the source code folder. From there, we can easily configure stuff like CPU resources, deploy environments, alerts and service dependencies. Then the second aspect to the OneTouch framework is this magical k tool, which is a command line tool built on top of Kubernetes that allows us to deploy our services to different environments on the Kubernetes clusters. If I just type k all on a command line, it will automatically generate the configs, build the app, and deploy it to a remote cluster. If you think about it, it’s actually just like making a bowl of ramen where first you generate the bowl, which is the configs. Then you build the ramen, which is the actual application. Then you deploy the entire bowl of ramen with garnishes, and that is the end product. Because all environments are deployed the same way, we can easily make five beautiful bowls of ramen soup for different environments. From the service governance perspective, it makes it super easy for everyone to orchestrate, deploy, and diagnose a service, because there’s only one place to look and one process to learn.

Spinnaker

Lastly, we have Spinnaker, which is an open source continuous delivery platform that we use to deploy our services. It provides safe and repeatable workflows for deploying changes to production. One aspect that has been especially helpful for us is the automated Canary analysis. In this step of the deploy pipeline, we basically deploy both the old and the new snapshots to two temporary environments, namely, Baseline and Canary. Then we route a small percentage of production traffic to them. Then, key metrics about these environments such as error rates, are automatically ingested and fed into a statistical test that produce an aggregate score for the Canary, which has the new snapshot as measured against Baseline which has the old snapshot. Based on the score, the analysis tool will decide whether to fail or promote the Canary environment to the next stage in the deploy pipeline, which, for example, could be deployed to production or running more integration tests. In SOA, where so many services are deployed every single day, this helps us to release code changes at scale with confidence and ease.

Thanks to all these infra pieces, we were able to migrate our core product functionality to SOA within the span of two to three years, with an architecture like this. Of course, there are many other services that are not shown in this diagram. In total, we have more than 400 services running in production with more than 1000 deploys every single day.

What Does the Post-Migration World Look Like?

After all this work, you could think that we can now take a long nap in front of the computer just like this cat. We are not done. In fact, we haven’t started climbing the metaphorical hill that I mentioned in the beginning. What we realize is that with a sprawling architecture like ours, there are some important SOA tradeoffs that we need to consider before we continue walking in the same direction. For instance, it could sometimes take more time for engineers to ship a feature with SOA, because engineers need to acquaint themselves with and make changes in multiple services. Then they also have to deploy these different services in order before they can push out a feature. There’s also significant overhead in maintaining each of these services. On one hand, our system has become more reliable and highly available, because if one service is down, other parts of the SOA can still function. On the other hand, the proliferation of services along the stack also led to more developer friction. Furthermore, even though now our services are loosely coupled, it means that certain patterns of logic have to be repeated across different services, since it’s now harder to share code across service boundaries than before.

To continue the comparison, on one hand, our services are now individually scalable, which means that we can fine-tune our resource allocation by service instead of scaling the entire monolith. On the other hand, we face fragmentation and inconsistency in business logic, which makes it harder for us to have a full picture of what’s going on in the system. Lastly, on one hand, we achieved business agility by separating different parts of the product into different services that can basically iterate in parallel at the same time. On the other hand, it’s also easy to end up with a complicated dependency graph if there’s no rules around who can call who. That’s what happened to us where due to unconstrained call patterns between services where basically anyone can call anyone else, we have this dependency graph with unruly arrows pointing in every single direction. This is unideal and potentially dangerous, especially when there are circular dependencies, which can make relationships between services hard to visualize and understand. On a good day, this could make it hard for a new engineer to ramp up on the system. On a bad day, when there’s an outage, this could make it difficult to debug errors and to mitigate user impact. In a tangled dependency graph like this, highly stable services can also be easily brought down by more volatile services. These are all flip sides of the same SOA coin that we have to grapple with.

Simplify Service Dependencies

To address these issues, we took a few steps, starting with simplifying service dependencies, which is our second takeaway. We designed our architecture to be a tiered tech stack consisting of presentation, mid-tier, and data services. The motivation was to separate services into layers as shown in this diagram, based on their technical priorities. As we go up the stack towards application and UI layers, the primary consideration here is iteration speed and schema flexibility, leading to more specific and fast changing API. On the other hand, if we go down the stack towards platform and infra layers, they need to have more generalized API and higher reliability requirements, since their blast radius is bigger, which means that if they go down, many other services will be impacted. For an SOA to be reliable and resilient, it’s imperative that stable services do not depend on more volatile services. Conceptually speaking, this means that a higher tier service can call a lower tier, but not vice versa.

However, the problem with our SOA system was that there was not enough service governance and dependency management to enforce this fundamental principle and to restrict who can call who. Hence, to enforce a topology-driven layer architecture, we introduce service blocks at a platform layer. You can think of each block as a collection of services with related business functionalities. For instance, the listing block, as shown here, will encapsulate both the data and business logic that inform core listing attributes. Then it will expose a simple, consistent read/write API to upstream clients through the facade. Under the hood, the facade will help to orchestrate the coordination between the underlying data and business logic services, while providing a layer of abstraction that conceals the underlying complexity from the clients. We also enforce a strict topology by prohibiting clients from calling any of the internal services, as well as prohibiting blocks from having circular dependencies with each other. With such a high level abstraction, it’s much easier for upstream clients to discover and leverage our core functionality at the platform layer. It is also much easier for us to manage block dependencies and maintain high levels of stability.

Platformize Data Hydration

We also spent some time platformizing data hydration. Going back to this diagram again, you can see that we have quite a number of presentation services. If we zoom into any of these typical presentation services, there are usually three common and straightforward functions that these services perform, including, first, which is data fetching and hydration from different downstream services. For example, Ramen service calls thousands of services to hydrate data for Host Reservation Details. Second, there’s also a simple transformation of data. Using the same example, Ramen service will transform and merge data from all these thousands of downstream services into something that the client expects. Then third, there’s also permission checks that we have to perform before proceeding with more complex business logic.

As time went on, we realized that engineers were spending a lot of time on these three common functions, resulting in a lot of duplicated code and wasted productivity. Our approach to this problem is to introduce a platformized data access layer that provides a single consolidated GraphQL schema, stitching together different entities across all of Airbnb’s data, for instance, listings, users, and reservations. Then, it also serves as one platform to host all the mundane data fetching and hydration logic rather than requiring duplication of this logic across many different presentation services. Together with a more complex presentation logic on the left and the write logic on the right, which we will ignore for this presentation, this common data access layer will eventually replace our old presentation services. Then the service blocks below the layer will also replace the old data and services. You can say that with this effort, we continue to simplify service dependencies.

Going back to the layer itself, it is this service building column that we call Viaduct, because it’s like a conduit for the data flowing through our entire system. In essence, it is an enhanced GraphQL engine that’s built in the language of Kotlin, that reimagines the way data is fetched in SOA, by going from service oriented to data oriented hydration. What do I mean by that? To give you a more concrete example, instead of writing code to explicitly call reservation data service to get reservation data, the caller will instead write a declarative query on the reservation entity. They will even fetch the associated listing and guest user data using the same query. Such GraphQL queries are made possible by our GraphQL schema that’s enriched with special directives. For example, the ServicePoweredType annotation with its templated fields allows us to associate a GraphQL type with a service endpoint, where the response from the service will be automatically used to hydrate the GraphQL type. Here you can see that we are linking the ReservationDataService endpoint, getReservationsByIds to the reservation GraphQL type.

As another example, the ServicePoweredType key annotation allows us to link different types together. For instance, the guestId on the reservation type can link to a fully-fledged user type that is implicitly fetched from the user block service. How the magic happens is that at build time, Viaduct translates these templated directives into auto-generated code, as represented by the field and type resolvers in this diagram, that basically takes care of the inter-service data fetching and simple data transformations. A resolver in GraphQL terminology is basically a function that outputs the value of a given field or type. In this diagram, the third-party GraphQL library is responsible for first parsing the incoming query, and then calling the resolvers for every field that we can process. In turn, the field resolvers will call the type resolvers to fetch data from downstream services. Aside from these directives, there’s also a privacy directive that wires in permission checks automatically, and ownership directive that makes it easy for us to find code reviewers and to route alerts to the right teams for all these different types at Airbnb.

Another cool directive is the derivedField directive, which allows developers to create new fields computed from one or more existing fields. For example, this HostFacingStatus field is used in Host Reservation Details page to call out important stages or milestones of a reservation to a host. For instance, it can take on the string values of pending payment, checking out today, review guests. To compute this status, we need to consult listing reviews and payment data, which will come from other parts of the GraphQL schema. With the derivedField annotation, we can tell Viaduct to resolve this derivedField using the business logic defined in the HostFacingStatusProvider class.

Going into this class, this provider class basically implements a standardized interface, and overrides two key methods. The first one is this getFragments method that allows us to define data dependencies for this DerivedField in terms of a GraphQL query. You can see here that we are fetching data from listings, reviews, and payment. Then, second, we have this resolve method, where we will write the actual business logic for resolving the DerivedField. What actually happens when a DerivedField gets resolved is that it makes additional field resolver calls, it can be multiple calls, to satisfy its data requirements. In effect, it creates its own GraphQL engine, which can instantiate field resolvers the same way that the other fields do.

Such an abstraction makes it easy for engineers to add all sorts of presentation logic without worrying about the nitty-gritty details of data fetching. You can imagine that when a query asks for multiple fields, especially multiple DerivedFields, it is easy to have overlapping data dependencies within the query. For instance, here you see that three field resolvers might end up needing data from the listing block service. To account for such scenarios, Viaduct has this built-in capability to batch the requests that it sends to downstream services in an optimized manner, making sure that it is not making more calls than necessary. The batching logic here is encapsulated by this dataloader wrapper around each of the type resolvers.

Optimized Batching

Under the hood, Viaduct relies heavily on coroutines in the Kotlin language, which you can basically think of as lightweight threads. Within a single Viaduct request, each of these field resolvers will trigger a coroutine to resolve its field value. Some of the field resolvers might end up calling the same dataloaders. For example, here, you can see that the first two field resolvers both call the listing dataloader. Same for the bottom two field resolvers, which call the user dataloader. It is important to highlight here that the loadById method calls here don’t trigger immediate data loading, but are rather suspended, which means that it can be paused and resumed at a later time. This suspension feature is a feature of the Kotlin coroutines. Viaduct with its special coroutine dispatcher will basically wait until all the coroutines for this particular request have reached their suspension point, meaning that no more resolution is possible for that request, before dispatching the actual data loading requests to downstream services in batch. Here you can see that Viaduct has aggregated all the listing IDs in one call to the listing block service, and all the user IDs in one call to the user service respectively. Once the data comes back, Viaduct will pass back the data to the origin of your resolver coroutines, which will then resume with the results.

To go even one step further, we also added an intra-request cache, which basically keys on the global ID and the type of data to make sure that within the lifecycle of a single request to Viaduct, the same data doesn’t get requested from its source more than once. For instance, the same listing ID, or the same user ID does not get requested more than once. These two measures, optimized batching and caching for data loading, prevents unconstrained funnel of requests to downstream services.

Example – Listing Details Page

To give you a real-life example, this is the listing details page that gets used to check out a listing and book the listing. Naturally, this page depends a lot on listing data. Before with our first iteration of SOA, the presentation service responsible for hydrating this page will end up triggering 11 calls all together to the listing block service through our SOA maze. After migrating most of our presentation logic to Viaduct, then the number of calls is reduced down to one. You can see how with batching and caching, Viaduct helps to improve performance and saves us computing costs by reducing the number of network requests needed to serve a single page. In addition, we also have an online IDE built on top of the open source graphical library that makes it super easy for engineers to explore the schema, issue actual queries, and to inspect the data fetched. It is also the primary way that we use to test our local code changes, since the IDE can be easily hooked up to local and test environments as well.

All in all, a GraphQL schema that’s enriched with these configuration driven directives, allows developers to easily create types, construct an entire graph representing Airbnb’s central schema, and to fetch data easily without having to navigate our vast constellation of services. This means that product engineers can focus on product innovation, instead of writing the same data hydration code over again.

Unify Client-Facing API

Lastly, as we continue to evolve our SOA, we also decided to unify our client-facing API. In our original SOA diagram, each presentation service is usually maintained by a different product team. The implication of this is that each presentation service tends to define its own client-facing API and solve problems its own way. There wasn’t really a common set of best practices, and people sometimes ended up reinventing the wheel. This often resulted in inconsistent if not buggy user experience and lots of spaghetti code that is not really reusable.

UI Platform

Our solution to the problem is UI Platform, which is a unified, opinionated, server-driven UI system. To quickly visualize how it works, this is what the user sees on HRD, and this is what the UI Platform sees where everything on the page is broken down into a standardized section. Our idea is for the content and styling of the UI within each of these sections to be driven by the backend. This leaves the frontend with just a thin layer of logic that’s responsible for rendering these sections. In this diagram, on the presentation backend, you see that we expose a common schema to the client. You can see that each of the frontend clients has a UI Platform runtime that is responsible for interpreting the API responses from the backend, and rendering it into UI for the user.

Taking a deeper look into the standardized API response, you can see that it is broken down into two parts. First, we have a registry of all the sections that’s needed for a page. Then, second, is the screen structure, which expresses the layout of the sections on the page. For instance, we can say that we want the header section to be at the top of the page, and the card section to be right below it. Zooming further into each of these sections, here we have the schema definition on the left with a concrete example on the right. The example here is the user highlight section in HRD, as indicated by the section ID. Focusing just on the key attributes, we first have section data which represent the data model for the section. For example, here we have a list of user info, including where the user lives. Then, second, we have the UIComponentType field, which is an enum that is used to refer to the frontend UI component that should be used to present the data. In this case, we want to render the data as a bullet list. One thing to call out here is that it is possible for one section data type to be rendered by different UI component types, which gives us more flexibility and variation in UI design. More importantly, all these sections should be totally reusable across different services. For example, this user highlight section here can be shared between a guest facing and a host facing surface.

There are a few other key features of the UI Platform. First, we have support for different layouts and placement of sections on the page, which provides flexibility and range for product design needs. Second, with deferred sections, we can opt to delay the loading of more expensive sections to a second network request, which helps to improve the initial page load time and user experience overall. This is especially helpful for mobile clients that can have weaker internet signals than desktop web. Lastly, the framework also logs impression and UI actions of each section automatically, which is helpful for measuring user engagement when we launch a new feature. To make the developer experience easier, we also build out a web tool that allows backend engineers to visualize their API response in real time by copy pasting their API response payload into the textbox in a tool.

In summary, by driving the UI from the backend server, we can basically establish a clear schema contract between frontend and backend, and maintain a repository of robust, reusable UI components that makes it easier for us to prototype a feature. In addition, with pre-built sections, we could also easily push new content to the clients without waiting for the long mobile app release cycles on app stores. Since no client code changes are needed with pre-built sections. Lastly, by centralizing the business logic and presentation logic in the backend, instead of having it scattered across clients, we could also ensure a consistent user experience across all frontend platforms.

Where on the Spectrum?

On the spectrum of how server driven we are, we have been leaning very close to the side of fully server driven UI. Basically, after piloting the UI Platform for a few product launches, we noticed some issues. First of all, by driving the presentation logic from the backend, it makes it hard for the different frontend clients to leverage native improvements or building capabilities from their native OS platforms. For instance, the navigation styles or haptic feedback on Android and iOS, are done very differently and it is hard to server drive these things differently in a centralized manner from the backend.

Second, the UI Platform makes it easy for us to reuse existing sections to build new pages. However, for a brand new section, designing the schema and building it out involves close collaboration between the client and backend engineers initially. As our company continues to invest in the ambitious product roadmap, we need to find a way to decouple this very tight-knit frontend and backend workflows to speed up our iteration. We basically decided to scale back our server-driveness and move towards the middle of the spectrum where the UI Platform will become a thin screen building layer in our frontend architecture. In this version, the section will basically remain the primitive for screen building, but now sections can be orchestrated with either server-side logic or client logic. Meaning that some sections can remain server driven, but for the client-driven sections, the frontend will handle the UI presentation logic, while the backend will handle the business logic. This pivoting in our frontend strategy will hopefully give us more flexibility in supporting new products and give us more synergy and speed in developer collaboration.

Recap

First, we have the first lesson, which is to invest in common infrastructure early to turbocharge our initial SOA migration. In our case, we leveraged both open source and in-house technologies to lay a foundation for our SOA. Second, as you continue to expand and scale your architecture, you can consider to start simplifying your service dependency graph for long term stability. For us, we did it with service blocks at the platform layer. Third, platformize common patterns such as data hydration, so that product engineers can focus on solving new and important problems. For us, we built a Viaduct service to do the job. Lastly, unify client-facing API into a robust system of flexible orchestration and reusable parts to support product iteration. For us, we use the UI Platform to standardize our API.

One overarching theme in the progression of these takeaways is that we continue to streamline and fine-tune our layers of abstraction based on the way we work and the way we build our product. Starting from the infra layer with the common building blocks, to platform layer with the service blocks, and then to application and UI layer with Viaduct and UI Platform. What informed these stepwise improvements, were the common pain points experienced by engineers and end users. It’s true that sometimes it means that we have to undo our earlier work. That is fine. It is really hard to get everything right the first time anyways. The point is to keep evolving the architecture to improve developer experience and to serve prevailing business needs.

Conclusion

Going back to the metaphorical hill in SF again, when we set out to migrate to SOA, we were not expecting our path to include this steep climb up ahead. The lessons along the way were enriching, and the learning curve was in fact quite an exciting and fulfilling ride. We can’t say for sure that we have made it to the top of the hill, but when we survey our current tech stack, we begin to see that SOA is not a fixed destination. Instead, like a real city, it is constantly changing and evolving into something more resilient and lasting.

Questions and Answers

Wells: What’s the next thing you’re thinking we need to make a change here to improve stuff?

Liu: At Airbnb, we are now focusing a lot on further improving developer productivity now that we have this complex system of so many services being deployed and features being launched at the same time. Something that we are trying to speed up is a local developing environment. We used to have all these staging environments, test environments, and developers used to just push their local changes to one of the test environments and issue some request to make sure that their changes work as expected. Those test environments are static and they are maintained by the service owner.

Right now we are trying to pilot something different that is basically allowing any developer working on any service to just spin up a private group of cloud applications to basically run your changes on, and those can spin up or ramp down based on developer demand. It’s like an on-demand test environment that is connected to the wider staging environment of the different services in the ecosystem. In that way, hopefully we can speed up the deploy time, because in the past, when we deploy to specific test environments, we still have to go through CI checks and stuff like that. With a more private group that have safety boundaries around it, we can make things faster and bypass some of the checks. That’s something that we have been tinkering on and trying to get more adoption of within Airbnb.

Wells: You talk about service oriented architecture. I’ve been around long enough to remember we had service oriented architecture and we started talking about microservices. What do you see as the difference between the two? Why do you say service oriented architecture when you’re talking about these changes?

Liu: I think it’s just a process of how we socialize the idea within our company. I think, tech leaders at that time, they really just used the word SOA to push the concept wider to every corner of the company. I think partially it might be because, at the start, we were wary of splitting our logic into tiny services. We wanted to avoid using microservices, just because the term might be a little bit misleading or biased in just how it’s understood by most people, when they first hear it. It’s probably just like the process of how we communicate it, more than anything else.

Wells: Basically, microservices sound like they’re just going to be far too small.

Liu: From your perspective, is there a difference?

Wells: There isn’t. I really don’t think so. I think probably, it’s a good instinct not to get hang up on the size of services. Because where we built microservices architecture at the “Financial Times,” I think we did build far too many services, because we thought, they’re supposed to be small.

What are the biggest benefits of the presented service oriented architecture at Airbnb compared to the monorail? Scalability.

Liu: Scalability, for sure. I think the most important part is how it’s mapped to how our teams are divided. In very broad strokes, we have the guest facing teams and host facing teams, and we work on the logic on our website separately for those things. In terms of just iterating, and pushing out new features, breaking our monolith into different services allow us to just do things in parallel, instead of having just one long deploy train on this monolithic application. A guest change might delay a host change and stuff like that. I think that’s the main benefit.

Wells: Downsides?

Liu: Just fragmentation of logic. Right now we are moving from being fragmented and having a lot of services to consolidating some of this logic. We’re trying to start from the more bottom layers of our tech stack, so starting from the platform layers, we’re trying to group all these very commonly used data and logic into bigger service blocks, instead of having multiple services re-implementing the same thing.

Wells: My experience is definitely you end up moving things around as you realize you’re changing them all at the same time.

In addition to Ruby, what programming languages have you added to your stacks?

Liu: Ruby was used in the monolith. Right now we use a lot of Java in our backend services, and some Kotlin sometimes as well. For the data side of things, we use Scala.

Wells: Was the monorail completely decommissioned?

Liu: Unfortunately not. That’s one of the fine print in our presentation. There’s a different level of challenge when it comes to migration. There are just going to be some stuff that’s really hard to migrate out, or stuff that is important but not that critical, and no one has the time to migrate them out. Right now, monorail still serves some very legacy traffic. Another reason is some very old frontend clients, especially mobile clients like iOS and Android might still be talking to monorail endpoints. For those reasons, we have to keep it around for a while longer.

Wells: Is there a plan to say we’re going to get rid of it, or is it just we’ll keep a certain amount of it?

Liu: Our goal is definitely to decommission it completely. I’m just not sure how long it will take. There’s going to be a very long tail that might just take maybe a couple more years for the monorail to completely disappear. It’s not critical anymore. It’s just going to be a small component in our SOA. It will become one of the services basically.

Wells: How does the GraphQL layer talk with the service layer? Does it use Thrift?

Liu: Yes, that’s correct.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Subscribe on:

Apple Podcasts
Google Podcasts
Soundcloud
Spotify
Overcast
Podcast Feed

.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Posted on nosqlgooglealerts. Visit nosqlgooglealerts

“

”

Posted on nosqlgooglealerts. Visit nosqlgooglealerts

“

”

Article originally posted on InfoQ. Visit InfoQ

Web accessibility benefits all of us. Designers, developers, and testers can check for web accessibility and can make the web and services more inclusive, for instance by using semantic HTML, following web standards when coding, and testing for web accessibility. Countries are introducing regulations to enforce inclusive standards.

Josefine Schaefer will give a talk about web accessibility at the Romanian Testing Conference 2023. This conference will be held June 6-8, 2023, in Cluj-Napoca.

According to Schaefer, there are good reasons to care about web accessibility. It’s a basic human right as defined by the United Nations to have access to information and communications technologies, including on the web. And web accessibility benefits all of us, not only the people who experience some form of disability:

If you look at your phone in bright sunlight, you will benefit from sufficient color contrast, if you are in an environment where you can’t turn up the volume, captions will help you understand the content of a video – there are so many examples just like this.

Schaefer will talk about using semantic HTML and the benefits that it can bring. Semantic HTML means using the HTML elements for their given purpose – like using an H1 for the most important headline, or the button element when using a button. It provides context for users of assistive tech and as an added benefit, native HTML elements bring a lot of inherit functionality that you would otherwise have to add manually:

This could mean adding the correct type to an input element, making sure the headline structures are hierarchical, and reflecting on the usage of divs.

According to Schaefer, there are tools to help you when testing for web accessibility. You can test keyboard accessibility by manually tabbing through a page, but you could also use tools like for example taba11y to visualize the tab flow. There are also more general tools like the axe dev tools which will help you audit your page and guide you through points that could be improved. For color contrast, there are many different tools as well helping you evaluate the contrast ratio between your foreground and background.

InfoQ interviewed Josefine Schaefer about improving web accessibility

InfoQ: What are the different aspects of web accessibility?

Josefine Schaefer: One of the most common issues is related to color contrast. This means providing enough contrast between the background and the foreground so that content is perceivable.

Another important aspect is keyboard accessibility: we want to make sure that websites can not only be used with a mouse or a trackpad, but users can also navigate with a keyboard or assistive technology.

InfoQ: How can we improve keyboard accessibility?

Schaefer: Make sure that all interactive elements like links or buttons are reachable with the keyboard as well – not only with the mouse or trackpad. Check whether the focus on the active element is visible and has enough color contrast. If you are working with hover styles, be sure that the information is also conveyed for people who might not hover but tab through a page. And of course, check that you are not “trapping” your users anywhere. There shouldn’t be any points of an application that can not be exited without a keyboard.

InfoQ: What will the future bring us in web accessibility?

Schaefer: I am hopeful that the future will bring even more awareness of the importance of web accessibility and the many different aspects that it includes. Ideally, this will mean a shift towards completely normalizing testing for web accessibility in software & web development. More and more countries are introducing regulations to enforce inclusive standards, which is one of many steps toward making it the norm. I also hope that awareness for so-called “invisible disabilities” will increase, shedding a light, among others, on neurodivergent folks and their experiences.

InfoQ: If InfoQ readers want to learn more about web accessibility, where can they go?

Schaefer: W3 provides a very detailed overview of the web accessibility fundamentals. There are also community-driven projects like the a11y project, which lists many resources and great articles on different accessibility-related topics. A11ycasts with Rob Dodson is also a great resource to learn more about web accessibility.

Article originally posted on InfoQ. Visit InfoQ

GitHub has announced a new SBOM export feature meant to be used as part of security compliance workflows and tools. The new feature allows you to export NTIA-compliant SBOM easily, says GitHub.

Users can export SBOMs in a number of different ways, either manually or through an automated process. To generate the SBOM manually, you visit the dependency graph of your repository and click the new Export SBOM button.This will create a machine-readable SBOM in the SPDX format.

SPDX, short for Software Package Data Exchange is an open format specifically defined to describe a software bill of materials, including any dependencies, licenses, copyrights, and security references. There exist many tools, both commercial and open-source, that can be used to consume SPDX files to validate, analyze, or convert them to other formats.

Besides using the GitHub Web UI, it is also possible to export SBOMs using a GitHub CLI’s extension or a GitHub Action.

The GitHub CLI extension can be installed by running gh ext install advanced-security/gh-sbom. After that, gh sbom -l will output the SBOM in SPDX format, while gh sbom -l -c will use the CycloneDX format.

As an alternative to the GitHub CLI, a GitHub action can be used to export SBOMs at build time. GitHub provides its own GitHub Action to export an SBOM from a dependency graph. If you prefer it, you can use Microsoft sbom-tool, or Anchore SBOM Action, which is based on Syft.

In future, the company says, exporting SBOMs will also be possible through a specific REST API.

An additional possibility offered by GitHub is uploading an existing SBOM to a repository to generate a dependency graph. This can be useful to organizations that prefer not disclosing all the dependencies they are using in their software. Once a dependency graph is generated, it becomes possible to receive Dependabot alerts for any vulnerability discovered in the repository or any of its dependencies.

It is important to understand that an SBOM, while required in many industries and at the US government level, is only one of many tools that can be used to protect a software supply chain. It will not solve by itself the problem of a dependency being potentially compromised, but it will help you better gauge the security risk associated by your implementation choices and understand who you are trusting, recursively, by including a given dependency into your system.