SonderMind

sondermind

When I started my career as a developer, my continuous integration workflow looked like this: Open FTP client Connect to the server Drag index.php from left to right Close FTP client My internet connection was slow, but it only took a few seconds to "deploy" my PHP application. I was new to programming, but I was able to get my code into "production" in just a few seconds. It was a great feeling to see my first website live on the internet. I have to admit, testing wasn't really automated, but my human CD pipeline was fast and reliable. If you think about it, this was actually "Serverless". I didn't have to worry about servers. I just had to upload my code to the "webspace" and it was live. Next, I wanted to add a database to my application. Here's the simplest code example I can find today: <?php$servername = "localhost";$username = "username";$password = "password";$dbname = "myDB";

// Create connection$conn = new mysqli($servername, $username, $password, $dbname);
// Check connectionif ($conn->connect_error) {  die("Connection failed: " . $conn->connect_error);}

$sql = "SELECT id, firstname, lastname FROM MyGuests";$result = $conn->query($sql);

if ($result->num_rows > 0) {  // output data of each row  while($row = $result->fetch_assoc()) 
{    echo "id: " . $row["id"]. " - Name: " . $row["firstname"]. " " . $row["lastname"]. "<br>";  }} else {  echo "0 results";}$conn->close();?> I f you copy this file to the web server, you have a fully functional application that can read and write data from a database. It's incredible how simple this concept was. A complete application in just one file. The "application" starts when the user opens the URL in the browser, and it ends when we're done sending the response to the user. That's as "Serverless" as it gets. Nowadays, we've gone absolutely crazy. We have AWS, Kubernetes, CDK, Terraform, Docker, Serverless, GraphQL, gRPC, REST, and so much more. You need many years of experience to be able to set up a project with this "modern stack". It's pure madness. You need Webpack or another tool to bundle your code, minify and optimize it. Build and publish Docker images, or upload zip files to AWS Lambda. And then there's yaml all over the place to configure your infrastructure. Architects proudly show off their "serverless" architecture diagrams on conferences with hundreds of components. I think to myself: "Why is this so complicated?" Why are there so many moving parts? There are specialised AWS consultants who earn a lot of money because nobody understands Cloud anymore. Our goal is to change this. We want to make using the cloud as easy as it was in the old days. But first, let's take a step back and look at the problem from a different angle. [ The rise of NextJS and Vercel From the early days on, I really enjoyed working with ReactJS. But for the first few years, there was a huge problem. I was constantly on the lookout for the perfect "boilerplate". Getting ReactJS right wasn't easy, especially if you want to have server-side rendering, hot reloading, and all the other features that make for a great developer experience. Then, in 2016, a new project called NextJS was released. It took NextJS a while to win the hearts of the community, but today it's the most popular ReactJS framework. With NextJS, I was able to stop my search for the perfect boilerplate. The framework might not be perfect in every way, but it's good enough for most projects. I can focus on the actual application instead of spending hours on figuring out how to do X. That said, NextJS wasn't alone. Along with NextJS came Zeit, a company that was founded by Guillermo Rauch, later renamed to Vercel. In Germany, we like to say "Es wird höchste Zeit" which means "It's about time". Vercel was the first company to understand that it's about "Zeit" to make deploying frontend applications easy. Vercel developed a simple but powerful playbook: Create an opinionated open source framework to consolidate the work of the community Add features that focus on developer experience, productivity and ergonomics Build a hosting platform that deploys your code on git push Abstract away the complexity of the underlying infrastructure so developers can focus on their code With this playbook, we're almost back to the simplicity of the PHP example above. Unsurprisingly, NextJS adds more complexity than a single PHP file, but we get a lot of value in return. Most importantly, we're back to the simplicity in terms of DevOps. Instead of dragging files from left to right, we just push our code to a git repository. The rest is handled by the hosting platform for us, and we're not just talking about a simple hosted NodeJS server. Vercel creates Serverless functions for server-side rendering, provides a CDN for static assets, runs middleware on the edge, integrates with GitHub, and builds previews on every git push. Now that we have NextJS and Vercel, we can say that "Frontend" is a solved problem. But what about the backend? Finding the right platform for the backend is hard When you ask developers where to host their backend, you'll get a lot of different answers. What all of them have in common is that they require a lot of DevOps and infrastructure knowledge. They offer you Redis and Postgres, they talk about Docker and containers. They have endless documentation and tutorials on how to set up the database and so on. Compare this to the simplicity of NextJS and Vercel. Backend seems to be years behind frontend in terms of simplicity and developer experience. That's why we decided to build WunderGraph the way we did. We want to create a "pure" backend framework that is as simple as NextJS, combined with a hosting platform that abstracts away the complexity of the underlying infrastructure. WunderGraph, an opinionated approach to backend development Similarly to NextJS, WunderGraph needs to be opinionated to create a great developer experience. Here's an overview of the most important decisions we made: The primary programming language is TypeScript WunderGraph supports multiple API styles server-side GraphQL as an integration layer JSON-RPC to expose internal APIs REST to expose external APIs Event-driven APIs for asynchronous workflows Configuration through code Touching infrastructure is optional Type-safety whenever possible TypeScript TypeScript is a perfect balance between adoption, language features, and performance. It's not ideal in every way, but perfect for configuration as code and implementing middleware and APIs. Multi API style No one API style is perfect for every use case. For us, GraphQL is the perfect language to integrate and combine multiple APIs. However, we're not directly exposing GraphQL, but only using it as a server-side integration layer. WunderGraph exposes internal APIs via JSON-RPC, while using REST when we'd like to expose APIs to third parties. For internal workflows and complex use cases, we're also offering event-driven APIs with asynchronous event handlers. Instead of forcing our users into a single API style, we're offering different options to choose from. Configuration through code Middleware, API, and event handlers are implemented in TypeScript, and we're using the same language for configuration as well. It's a single codebase for everything, not a single YAML or JSON file is needed. Touching infrastructure is optional It's possible to go from zero to production without touching any infrastructure, but we don't want to magically hide the underlying infrastructure from the user. You can always plug in your own infrastructure, like a Postgres database or Redis cache, but you don't have to. Type-safety whenever possible We want to avoid runtime errors as much as possible. The type system of TypeScript helps us a lot to achieve this goal. Sometimes, it might be favourable to have a bit more flexibility, but we're trying to avoid this as much as possible. Infraless backend development What are the most critical building blocks of a backend (in no particular order)? authentication & authorization database key-value store caching file storage cron jobs long-running operations job queues and async workflows logging monitoring automated deployments We're not reinventing the wheel here. We're using existing open source projects to implement the interfaces and offer them as one unified set of lego blocks. Let's dive into the details. Authentication & Authorization It's a problem that is already solved by WunderGraph. For authentication, we rely on OpenID Connect. For authorization, we offer rbac and abac as well as injecting claims into API Operations, allowing for a lot of flexibility. Database We're using Prisma as our database abstraction layer. Prisma not only allows us to offer simple migrations, but also to introspect the database schema and generate TypeScript types for it. Key-value store A typical key-value interface might look like this: const client = new Client()await client.set('foo', 'bar')const value = await client.get('foo') The problem with this interface is that it violates one of our principles: type-safety. A more type-safe approach might look like this: // define key-value store with zod schemaconst store = new Store('fooStore', {    foo: z.string(),})await store.set('foo', 'bar')const value = await store.get('foo')console.log(value.foo) // bar This store is now fully type-safe. By giving it a name, we're able to evolve the schema over time. As long as we're not introducing breaking changes, the schema can be evolved. Caching Caching is a very important part of a backend. We'd like to offer multiple caching strategies, HTTP-layer caching (already implemented), and application-layer caching in the form of a key-value store with TTLs and eviction policies. We'll probably use one of the existing well-known solutions to implement this. File storage File storage is already implemented in WunderGraph. WunderGraph is compatible with any S3-compatible storage. Cron jobs It's very common to have cron jobs in a backend that should run at a specific time or interval. If you do some research on how to run cron jobs with AWS Lambda, here's what you'll find: You need to create a CloudWatch Event Rule You need to create a Lambda function You need to create a CloudWatch Event Target You need to create a CloudWatch Event Permission You need to create a CloudWatch Event Rule Input You need to create a CloudWatch Event Rule Input Target You need to create a CloudWatch Event Rule Input Target Permission That's a lot of steps to run a simple cron job. What if we could just write this: const cron = new Cron('myCronJob', {    schedule: '0 0 * * *',   
handler: async () => {        // do something    },}) Git push this code to WunderGraph cloud and you're done. Even if we were using CDK, this would still be a lot of boilerplate code. Long-running operations There are many use cases where you'd like to implement workflows that run for a long time. Temporal (formerly Cadence) is a great source of inspiration for this, as well as AWS Step Functions. Here's an example that made me fall in love with Temporal: func RemindUserWorkflow(ctx workflow.Context, userID string, intervals []int) error {   // Send reminder emails, e.g. after 1, 7, and 30 days   
for _, interval := range intervals {      _ = workflow.Sleep(ctx, days(interval)) // Sleep for days!      _ = workflow.ExecuteActivity(ctx, SendEmail, userID).Get(ctx, nil)      // Activities have timeouts, and will be retried by default!   }} The idea that you can write synchronous code which can sleep for days is amazing. However, this love quickly turned into confusion when digging into their documentation. I have to understand too many new concepts to get started with Temporal, like activities, workflows, signals, queries, etc. The same applies to AWS Step Functions. They don't feel intuitive to me. Configuring state machines via JSON is not how I envision writing workflows. I'd like to offer a similar experience to our users, but without this steep learning curve. Here's an example of how a workflow to onboard users could be implemented: const workflow = new Workflow<{ userID: string }>('onboarding workflow', {    states: {        welcome: {            handler: async (ctx: Context) => {                console.log("send welcome email");                
const ok = await ctx.internalClient.sendEmail('userID', 'welcome');                if (ok) {                    ctx.next('sendReminder');                }            }        },        sendReminder: {            waitBeforeExecution: '5 days',            handler: async (ctx: Context) => {                const loggedIn = await ctx.internalClient.queries.userLoggedIn('userID');                if (!loggedIn) {                    console.log("send reminder email");                    ctx.internalClient.sendEmail('userID', 'reminder');                }                ctx.done();            }        }    }});
const id = await workflow.start({userID: '1234'}); // id: 1const state = await workflow.getState(id); // state: 'welcome'// after one dayconst state2 = await workflow.getState(id); // state: sendReminder (4 days remaining)// after 5 daysconst state3 = await workflow.getState(id); // state: 'sendReminder'// after 5 days and 1 secondconst state4 = await workflow.getState(id); // state: 'finished' What's the beauty of this approach? Other solutions to this problem already exist. WunderGraph Workflows will be, like everything else, type-safe and easy to use. But most importantly, they are fully integrated into the rest of your application. Start workflows from an API Operation, trigger them from a cron job, or run them in the background. You can get the state of a workflow from anywhere in your application, like an API handler. Finally, you're able to run workflows locally and debug them just by running . Deploy your WunderGraph application to WunderGraph cloud and the state of your workflows will automatically be persisted. wunderctl up Final note: Workflows will be Serverless, meaning that they will sleep when they're not running. When a workflow sleeps, it really does. Therefore, you don't have to pay for a workflow that's not running. Job queues and async workflows Another common use case is to run jobs asynchronously. For this to work, you usually need a job queue and a worker that processes the jobs. This is a very common pattern, but it's not very easy to implement. You have to configure a queue, a worker, and a way to communicate between them. As the queue, you can use AWS SQS, RabbitMQ, Nats, or similar solutions. Then you have to configure workers to process jobs, report state, handle errors, etc. Finally, you need to implement the logic to enqueue jobs and handle the responses. But isn't this just a workflow with a different name? Yes, it is. Workflows will automatically be backed by a job queue. The communication is already handled by the workflow engine. All you have to do is to define a handler, possible states, and the transitions between them. Workflows don't have to have multiple states, they can also be just a single handler that runs asynchronously. All the steps to implement a job queue and a worker are already handled by WunderGraph. We're trying to abstract away the complexity to the minimum. Insights: Logging, Monitoring, Metrics, Alerting and Tracing Another important aspect of developing APIs and services is to have insights into what's going on. This includes logging, monitoring, metrics, alerting, and tracing. WunderGraph will offer a unified way to collect and analyze all of these insights. In addition to that, we'll offer you ways of integrating with your existing tools. Automated Deployments / CI-CD A critical part of achieving a great developer experience is to not have to worry about deployments. One of our users reported that they were able to build a POC with WunderGraph within one hour, but then it took them multiple days to figure out how to properly deploy it to AWS, including health checks, DNS configuration, autoscaling, and so on. We believe that this should be abstracted away, just like Vercel does it. You should be able to push your code to a git repository and have it deployed automatically. No additional configuration should be required. Good defaults should be used, but you can always override them if you want to. We've invested heavily to build the perfect CI-CD pipeline for WunderGraph. It's based on top of Firecracker and is able to build and deploy WunderGraph applications in less than a minute. We'll talk about this topic in depth in a future post. Summary In this post, we demonstrated how an opinionated approach can radically simplify the existing workflow of building software. You don't have to understand the entire AWS ecosystem to build rich backend applications. It's clear that we're making trade-offs here, but we believe that the benefits outweigh the downsides. As I said earlier in the post, it's about "Zeit" (time) to simplify cloud-native software development. Serverless was a great start, but I think that we should go one layer above, abstracting away infrastructure completely. Back to the old days of PHP, but with a modern twist. We'd love to hear your thoughts on this topic. How do you think about abstracting away infrastructure as proposed in this post? Do you want to control every aspect of your infrastructure, or do you prefer to have a more opinionated approach? Additionally, we'd love to invite you to the WunderGraph community. Please share your opinion on our , and join the early access program if you're interested in trying out WunderGraph Cloud as soon as it's available. WunderGraph Cloud Early Access Discord server Are you ready for the next generation of Serverless Infraless API Development? Join the waitlist for WunderGraph Cloud Early Access and be the first to try it out. Also Published Here

Dev without Ops - Why we are building The Vercel for Backend

I know her from her beautiful avatar, who always looks sharp at all Decentraland events. She was one of the first users I've found on Twitter to follow who actively participates in web3 space. On a sunny Sunday evening, I talked to Maryana. She is one of the few female Decentraland Twitch streamers. It's 8 am where she's at and 3 pm where I am. As we log in to our google meets, we keep joking about the time difference and how difficult it is for me to attend events in Decentraland that usually happen while I am asleep. Maryana admits - this is the first thing that needs to be improved – flexibility in event timing. There should be more timing options for people not in the USA. You're not the first person I am hearing this from! Maryana: Only crazy people come to the events that are on 2 am in their local time. It's not fair! Maryana says it should be more before 8 am (USA time) events, and she checks the total users on Decentraland as we speak - 902! Tell us, who Maryana is, and what is your background? I am from the USA. I come from a finance background. I learned about blockchain four years ago, but back then, I was too young or didn't have money to invest in crypto or dive into the blockchain too much. Also, the concept was pretty new to me, so I didn't fully understand its potential. Maryana: I've been trying to learn about web3 and coding. Been networking a lot. I used to attend a few blockchain events before covid. Besides that, I do a lot of hobby photography and videography. But I am just a normal person working. (laughs) We talk a lot about those two sides that are important for someone joining the Decentraland, the only active open virtual world at this moment. But I am curious how someone like Maryana entered the space? I didn't get into it until I entered Decentraland in December 2021. I had a Metamask wallet since April last year. I had some friends into buying and making photography NFTs. We were always on Clubhouse talking about photography coming to an NFT space. So I set up a Metamask. However, I never knew how to transfer money. I had a Coinbase account, but I always was nervous about making a transaction to my Metamask. So honestly, Maryana: (web3 space - editors note) I didn't make my first NFT transaction until I posted my first wearable in Decentraland. So Decentraland helped me learn how actually to transfer money. Now it's a curse, because if I have MANA - I need to go shopping. (laughs) Tell us a little bit about project B-Verse. Was it the reason you became more active in Decentraland space? It's one of the reasons. It started as a little business networking group. In January, GoldGuy and Alpha started doing these business discussion meetings every Thursday in a random Decentraland location. They just got sick and tired of always partying, and they wanted to meet more IRL businesspeople who would enjoy talking about business, growing, and just networking. With time it grew, and many people became more interested in it. They discussed what it's like to be in the Metaverse and how they can make a Decentraland a better place. Maryana: I joined around the third meeting, and they were super happy to have more women in the space. I just wanted to come in, be lowkey, and play games. So that was just my only goal in Decentraland - just to hit rocks and walk around. Actually, when I came to Decentraland, I didn't want to show my IRL professional persona. Have you ever met your partners in person? No, the only people I have met in Decentraland were Bokkeh, Emtastic, and Klow from WisherVodka. Once, I was at a party at Klow's house. I want to get better at meeting more people or going to events. Maryana: As we talk about shopping in Decentraland and who are the best creators out there, I have to ask Maryana about the few dresses that she created some time ago and why she stopped doing that. What about creating wearables? Since B-Verse and twitch streaming, I haven't been into wearable creating because of the limited market in Decentraland - it's just so slow, and even if I make a wearable, I will only sell two items due to a low consumer base. It's just not the right thing to do right now. With high design fees, it is hard to break even. Maryana: Do you think you would be back to wearables once it's improved, or will you focus on business and communication more? Well, I doubt it will solve the problem of not having enough customers to buy wearables. So I will focus on Metaverse education and the B-Verse network. Because right now, the biggest gap in web3 is not enough people here from web2. I am trying to always go to other web2 platforms trying to meet people who would be interested in joining. I have a goal to get those people over here. Maryana: Everyone has these side ambitions. For example, you're into fashion and not a gamer, so each avatar has a story behind it. I'd love to meet everyone, have calls like this, and talk in Twitter spaces where you can hear people's voices. So it's not just a game. Decentraland could be a place to business network, and it could help you in your IRL career. People imagine Decentraland being a game, more like Roblox. Still, in my eyes, it's more like social media platform, represented by an avatar, because everyone here is the real people (hopefully, haha). What is the biggest challenge in the Metaverse? Talking about the Decentraland - accessibility. Right now, the only way to enter is through your laptop. However, you're not going far if you don't have a decent computer. Maryana: I share my experience with Maryana; as I tried logging into Decentraland, I thought my computer would burn. What about other Metaverses? I tried Cryptovoxels and Spatial once or twice each, and it's not as heavy on your computer as Decentraland. Once I tried Cryptovoxels and Spatial, I thought I would rather stay here because it's just so much easier on my computer, and you can access it on your phone too. Unfortunately, I never see many people on Spatial, so I am still trying to figure out where that community is. Maryana: Going back a little, how did you actually HEAR about Decentraland? First, I heard of the concept of virtual land back in 2018/2019. It was the earth2 io project. Back then, I didn't know its purpose and what you could do with it. And then, as I started learning more about photography NFTs, my TikTok became NFT and crypto-based immediately. Maryana: I heard the concept of Decentraland on TikTok. The only reason why I stopped to listen to it was that I'd heard of the concept of the virtual land before. And I actually watched a WonderMine video about how you can make a free NFT, and it's funny because 7months later, I didn't make any NFT, haha. So I told my husband, "Omg, I can go to Decentraland, play a game for 30 days, and get a shirt NFT, and I can sell that NFT!" Back then, I didn't know what wearable NFT was. I thought I could easily flip it. Nope, never even had a chance to enter that business because I got so busy! How do you manage your time in Decentraland? It should take a lot of time! I know it takes a lot of my time! I think I got so ambitious in the first few months, so I was probably not sleeping enough then. It was very unhealthy, so I have been cutting that back for the last few months. I've been regaining my real schedule. I am not logging in as much as I used to because I try to enjoy my real life now. I only log in to Decentraland about twice a week at this point. Maryana: I used to be up until 4 am each night, and after working my real job, I was spending 12 hours in Decentraland. Every Monday, I do DCL Report for an hour and go to a party once in a while. I am more at this building phase right now. I've been trying to make more content on the topic, but it's so hard because my job takes a lot of my time. Do you see yourself working in the web3 space as your full-time job? It's definitely a goal. If it's possible financially, I'd love to do this full-time. Unfortunately, as I initially thought there would be, cash flow returns are not there yet unless you're working for a reputable, established web3 company. Maryana: It's nice to be here in the beginning. I hope one day I can say I remember when there were just two people in web3, haha. I just want to be a part of something that might scale to be something crazy in a few years. Maryana, who are your Decentraland favorite members? Maryana: KevinOnEarth999 GoldGuy Canessa Roustan WisherVodka Digifun Later, we carry our conversation towards more personal things, such as people being hacked and their wallets drained. Maybe a little bit of high school drama and community still being so small. We briefly touch on the topic of gender in web3 space and why gender-based communities don't work out the way they do in the web2 space, but I feel like this is a separate topic to talk about in general. It seems like Maryana lived through a lot in these couple of months, and I am grateful for her sharing it with me. Follow my insights on Decentraland and its community by subscribing to newsletter that comes out every week. The Wearables Daily

Stories, News & Mentions about SONDERMIND

Sondermind’s Stories on HackerNoon