Latest Tutorials

Web MIDI API is an interesting tool. Even though it has been around for a while now, it is still only supported by Chrome. But that's not gonna stop us from creating a playable synthesizer in Angular. It is time we bring Web Audio API to the next level!Previously, we spoke about declarative use of Web Audio API in Angular . Programming music is fun and all but how about actually playing it? There is a standard called MIDI. It's a messaging protocol for electronic instruments data exchange developed back in the 80s. And Chrome supports it natively . It means if you have a synthesizer or a MIDI keyboard — you can hook it up to a computer and read what's played in the browser. You can even control other hardware from your machine. Let's learn how to do it the Angular way. There's not a lot of documentation about it other than the specs. You request access to MIDI devices from navigator and you receive all MIDI inputs and outputs in a Promise . Those inputs and outputs (also called ports) act like event targets. Communication is performed through MIDIMessageEvents which carry Uint8Array data. Each message is 3 bytes at most. The first one is called a status byte . Every number has a particular role like key press or pitch bend. Second and third integers are called data bytes . In the case of key press second byte tells us what key is pressed and the third one is the velocity (how loud note is played). Full spec is available on the official MIDI website . In Angular we handle events with Observables so first step to adopt Web MIDI API would be to convert it to RxJs. To subscribe to events we first need to get MIDIAccess object to reach all inputs. As mentioned before, we request it from navigator and we get a Promise as a response. Thankfully, RxJs works with Promises too. We can create an Injection Token using NAVIGATOR from @ng-web-apis/common package. This way we are not using global objects directly: Now that we have it, we can subscribe to all MIDI events. We can make Observable two ways: Since in this case there is not much set up required a token would suffice. With a bit of extra code to handle Promise rejection, subscribing to all events would look like this: We can extract particular MIDI port from MIDIAccess in case we want to, say, send an outgoing message. Let's add another token and a prepared provider to do this with ease: To work with our stream we need to add some custom operators. After all, we shouldn't always analyze raw event data to understand what we're dealing with. Operators can be roughly broken into two categories: monotype and mapping . With the first group, we can filter out the stream to events of interest. For example, only listen to played notes or volume sliders. Second group would alter elements for us, like dropping the rest of the event and only deliver data array. Here's how we can listen to messages only from a given channel (out of 16): The status byte is organized in groups of 16: 128–143 are noteOff messages for each of the 16 channels, 144–159 are noteOn, etc. So if we divide status byte by 16 and get the reminder — we end up with that message's channel. If we only care about played notes, we can write the following operator: Now we can chain such operators to get a stream we need: Time put all this to work! With a little help from our Web Audio API library discussed in my previous article , we can create a nice sounding synth with just a few directives. Then we need to feed it played notes from the stream we've assembled. We will use the last code example as a starting point. To have polyphonic synthesizer we need to keep track of all played notes so we will add scan to our chain: To alter the volume of held keys and to not end sound abruptly when we let go we will create a proper ADSR-pipe (the previous article had a simplified version): With this pipe we can throw in a fine synth in the template: We iterate over accumulated notes with built-in keyvalue pipe tracking items by played key. Then we have 2 oscillators playing those frequencies. And at the end — a reverberation effect with ConvolverNode . Pretty basic setup and not a lot of code, but it gives us a playable instrument with rich sound. You can go ahead and give it a try in our interactive demo below. In Angular, we are used to working with events using RxJs. And Web MIDI API is not much different from regular events. With some architectural decisions and tokens, we managed to use MIDI in an Angular app. The solution we created is available as @ng-web-apis/midi open-source package. It focuses mostly on receiving events. If you see something that is missing like a helper function or another operator — feel free to open an issue . This library is a part of a bigger project called Web APIs for Angular — an initiative to create lightweight, high-quality wrappers of native APIs for idiomatic use with Angular. So if you want to try Payment Request API or need a declarative Intersection Observer — you are very welcome to browse all our releases so far .

In this blog post, we discussed the role of entryComponents in Angular applications. We saw how before Ivy, we needed to add all the dynamic/web components to the entryComponents array inside NgModule to ensure that its NgFactories are available at the runtime, and we saw how after Ivy, we do not need entryComponents at all since we do not need to have Ngfactories for the components now in Angular.With angular 9, there has been a lot of talking going on around entryComponents, and the Angular developers who had not been much aware of entryComponents have now been interested in knowing more about it. In this blog post, I will try to cover everything that might help you clear up all the thoughts you have around the usage, importance, and the goodbye of  entryComponents . The best way to start understanding what  entryComponents  are would be by first trying to understand component renders in Angular and how really does the compiler play a role here. So just for a visual understanding of what we are talking right now, I have added below a snapshot of the component declarations inside the root module. Basically, there are two types of component declarations, ones which are included as a reference insides templates, and the other ones which are loaded imperatively. When we reference the component inside templates using the component selector, that’s the declarative way of writing components. Something like this: Now, the browser doesn’t really understand what  app-instruction-card  means, and therefore compiling it down to what browser would be able to understand is exactly the Angular compiler’s job. The imperatively written template for, for example,  app-instruction-card  would look something like this: This creates an element with your component name and registers it with the browser. It also checks for change detection by comparing the old Value with the current value and updates the view accordingly. We write templates declaratively since the Angular compiler does this rendering bit for us. Now, this is where we we can introduce ourselves to what entryComponents are! Before Ivy, Angular would create Ngfactories for all the components declared in the template and during the runtime it would enable tree shaking for the components not used. This is why the dynamic components with no Ngfactories could not be rendered and would throw an error like: No component factory found for a my-dynamic-component Adding the component to the  entryComponents  array would then make the factories for these dynamic components available at runtime. How Angular specifies a component as an entryComponent behind the hood can be in different ways. Using ngDoBootstrap() and using the same imperative code to declare a component bootstraps it and makes it an entry component into the browser. Now, you’d be wondering that if entryComponents have such a massive role to play in component declaration, why do we as developers see it rarely used? As we discussed above, entryComponents are mostly specified in two ways, bootstrapping them or defining them in a router definition. But since these happen under the hood, we hardly notice it. However, when working with dynamic components, or web components in Angular, we explicity define the components as entry Components inside the  entryComponents  array. Inside @ NgModule , we can define the component inside this array: Alright, think for a minute. When we declare multiple components inside the declarations array of our modules, does that mean all these components will be included inside the final bundle? This is where  entryComponents  have a role to play. So the answer first of all the above question is NO. All declared components aren’t necessarily present in the final produced bundle. It is if they are specified as entryComponents what decides if they’d be present in the produced bundle. This basically means that all the routable components will be present in the bundle for sure and also the bootstrap component obviously. This would also include the bundles that are declared inside the templates of other components. However, the tree shaking process will get rid of all the unused components with no reference without having to include them inside the package. EntryComponents  are mostly explicity defined when dealing with dynamic components, like I said before. This is because there needs to be a reference for the compiler to understand that  THOUGH , there is no reference for a particular component in the template or router for now, there is a possibility for it to be rendered dynamically when required. The  ComponentFactoryResolver  takes care of creating this dynamic component for us but we specify this inside the entryComponents array inside NgModule. If you have worked with dynamic components before, you might have faced an error like: Now knowing why need entryComponents, lets discuss a scenario where in we have created a dynamic component and have added it to the entryComponents array. This basically means that now since we explicitly declared it as an entryComponent, the tree shaker would not prune this component thinking that it doesn’t have a reference in the template. Also, specifying it as an entryComponent would create a component factory for this dynamic component. First, the entryComponent for a particular dynamic component could be added automatically whenever a dynamic component was created to be used. So this would save the developer from specifying it everytime to make sure the compiler knows the component. One more issue with using entry component was referencing the entryComponents declared inside a lazily loaded module. So if a lazy loaded module contains a modal component as an entry component, you’d face an error like  No component factory found for this component.  This was because the root injector couldn’t be referenced to create a component factory for the entryComponent. One solution, though not very promising was creating a component resolver factory yourself for a particular entry component inside the lazy loaded module to be able to execute it. With Angular 9 coming in and Ivy as the new rendering engine , all the components would be considered as  entering components  and do not necessarily need to specified inside the entryComponents array. With Ivy, the components will have locality and this means that dynamically importing these dynamic components will always work regardless of presence of entryComponents or ANALYS FOR ENTRY_COMPONENTS. This is because NOW, there would be no Ngfactories at all. Rendering the component is based on the static properties θcmp and θfac. See the update from the Angular official documentation here: https://next.angular.io/guide/deprecations#entrycomponents-and-analyz for entry_components-no-longer-required A demo here shows how entryComponents are longer required with Angular 9 https://ng-run.com/edit/bY1pxzWwKrEqPOjevXnS

In this post, we will be discussing conditional rendering in React and the different methods we have at our disposal to achieve this.One of the biggest challenges we face when building applications is making sure we render the correct components/elements for our user e.g. we don't want to show a login form to a user who is already logged in. You want this experience to be seamless and not affect the performance of your application. Conditional Rendering in React behaves the same way as conditions in JavaScript, so once you understand conditional operators, you'll understand conditional rendering. Conditional Rendering, therefore, gives us the ability to render what we want to on the screen based on the current state of our application. Pretty great! So let's learn the different ways we can conditionally render in React. By the end of this post you will be able to: To get the most of this article, we assume you're familiar with the component basics in React and also core JavaScript (variables, conditional statements etc). We'll also be using the basics of React Hooks. If you do not know any of the above but would like to learn, here are some great resources: Now let's get into it! Let's first look at a typical functional component: This will return Hello World onto our screen. How about we add a prop to this component that has a boolean called sayHello . When the boolean is true we return Hello World else we return Goodbye World . If we were using vanilla JavaScript, this would be quite difficult to achieve and we would have to toggle different styles for the component. Thankfully, React has made this much easier! Wow, how simple was that. Believe it or not, we can even make it a little cleaner using a ternary. If you want to play around with the above, here is a Codesandbox. With the fundamental knowledge we need in place, we can move onto more real-world examples. When building web applications the majority of the time we will have some sort of user authentication. The authentication flow will generally be like: If we were to implement this in React, it would look like as follows So we first declare a variable in our state called isLoggedIn and this is changed using the setLoggedIn method (if you are not familiar with react hooks you can check out the docs here ). We then create a Login and Dashboard component (we have no login validation in place as we want to keep the code as minimal as possible). I am using react-bootstrap for the styling, so we can focus on the code, you can check out the docs here . So each component has a Button that triggers the different state for login as visualized below. Great, we now have everything in place - I bet it was a lot easier than you thought. Here is a Codesandbox that you can play around with. Let's look at a different example where instead of hiding an entire component, we can hide just a small part of a component. It is very common when building a web application to hide some features to certain users, let's imagine we have a navbar like so: This navbar has an admin item that should be only visible to admin users. Our navbar component will accept in a prop to let the component know if the user is an admin or not. We can now do a nice little trick now using a double ampersand. We can conditionally render using a double ampersand which basically says if the value on the left is true then show the content on the right. In react terms our nav component looks like this: The key line above is: Again, we can see how easy react makes it for us to hide and show components. Here is the codesandbox so you can play around with the above example. The final component we will look at is a toggle component, it is quite common for the user to have the ability to show hide extra information on a web page. This could be on the click of a button that will show this extra information, the component could look like as follows: Like above we are using useState to manage the state and on the click of our button, we update the state. We are then using our showInfo state to decide whether we should see the extra information or not: If we were using vanilla JavaScript we would need to toggle hide and show classes on our p element which can become quite cumbersome, you can see how React removes this pain for us, Today we learned that Conditional Rendering in React behaves the same way as conditionals in JavaScript, we also went through the different methods we have at our disposal for conditional rendering. If you're interested in learning further, the React docs has a great section on conditional rendering. Have a great day.

By the end of this post, you will know how to use authentication in your project using React.I can't imagine anything in the tech world that would sound so similar and frustrates when you are trying to find the difference but Authentication and Authorization. As Front End developers we are facing these terms quite often, mostly to build system using it. But how exactly we can develop such a thing? What is the real difference? Let's start by defining how these terms differ from each other to understand how we could implement it in our app. Authentication is where your meaningful application usually starts and ends. It answers the question " Are you able to use this app or not? " For all kinds of applications, you'll most likely need that feature for various reasons. These things we are facing daily - Login/Password, 2FA, Certificates, Biometric like FaceID, TouchID, Physical tokens, OpenID - those are all approaches of Authentication. On the other hand, Authorization is the next step which answers a bit different question - " What can I do with your app? " Usual approach to get authorization is RBAC - Role-Based Access Control. As for extra examples of access control systems that can be used - ACL or ABAC . Though RBAC is defined as the go-to solution for most of the cases. It's not that important what kind of application you are building. Usual user interaction with your app will go as follows: Let's start with how we define Authentication. Interface for authentication is consist of 2 basics: Any approach to authentication gives you a way to generate an identifier that could be used in the system to process further requests. Any key that you have configured for authentication - login and password, 2FA time-based code, face or fingerprint used to generate the identifier. A service on your back end to recognize already logged in users. This function is in control of all user app activity. It handles how we are saving identifiers within our app, how long we are allowing users to use an app without religion. Here is how we can define Login flow and Authentication flow When building an authentication system the most challenging part is on the back end. You need to provide scalable service to work as a source of truth for all of your users. Building your own solution with default criteria like "I want to let users in by their email and password" or "I want also to let them in with 2FA for security reasons" most likely would just add extra service to increase your technical debt. Discuss with your team what would be more suitable for your product. There are good production-ready providers that could save your time: They usually come with different identification strategies already built-in. You can have social integration in 2 clicks. Some of them would also provide front end components that you can use or extend. Now we have Back End for our authentication following the process described above, it returns our identified user. We are ready to proceed with cool looking front end built with the currently popular framework. To do that with examples, we are going to use React + MobX + TypeScript on Front End and Express on Back End. If you are not really familiar with typed JS or observables, I would really recommend to check out these articles: React is the most popular library to build your front end at the moment. But there is no specific answer in the article as to why you should use exactly React, all approaches we are going to look at could be used with Vue, Angular or vanilla JS. We will use latest feature from React like hooks. If you haven't used them by now check this doc to get familiar with them. We are just about to build our web app and let all of our components to know about the user. Our front end work here is to: All of code examples could be found in the repository here . Our web app may have more dynamic requests for data or view but what we want to do here is put our request in parallel, so our user will be defined as soon as possible. To do that we have 2 ways when to trigger user load: As we most likely will have 1 user authenticated and based on that info we would proceed with further app logic, the first scenario is better for us. That's why we putting it in the place where we render the component. Let's start with defining function where we sending the request to our API to get the user. src/user/loadUserByToken.ts Here we are using axios as a library to fetch data, but pretty the same could be done with regular fetch request with defining a bit more info. As a mock for our user info, we are using service reqres.in . It just returns user info on specific IDs. We are loading user info by userId for demo purposes but in a real app, you will not have an id before you render. You will have your identifier stored in cookies, localStorage, sessionStorage on the user side. We need that to let our system know on user return and not ask a user to log in each time they visit our app. In the end, this identification will serve the same idea - ask API for authentication by identifier. src/user/userStore.ts Here is how we triggering this static request right before rendering app: src/index.tsx To serve the global state that should be accessible outside of component we cannot use only context and hooks so we will define a MobX store to follow our authentication process. But on another hand, we can have a case with the need to serve data only in component, for that we will use local state with hooks. Let's do examples on how saving could be done using both approaches. Define your User store, what data would you use in your app. Observables let us create simple objects without the need to create all actions around them, this approach is quite straightforward and best for demo purposes. src/user/userStore.ts After defining your store you need just to use it inside a component where you expect reading user data. To do that you need to get the user from this store, with injecting or importing directly - depends on your architecture. src/user/ExampleUserStore.tsx As an alternative approach to direct import, you could think about putting a wrapper around this store like useUserStore and inject your global user wherever you need it. src/user/useUser.ts Once we are about to render a component with the hook useUser it will create a local state with a user loaded if not found. As we may use this hook multiple times in different components we need to make sure we are not requesting redundant data when component not rendering anymore. That's why we defined cancel callback on useEffect return. Then in our actual component, we just using this as regular hook. src/user/ExampleUseUser.tsx If the user is not defined and we cannot proceed with the positive flow - we need to provide a fallback to our login page. It could be just a history replacement or usage of a provider like react-router. Within our simple page let's say instead of going to the different page we just want to replace our UI to show the input to say what user we are. src/user/Login.tsx This small component lets us define a wrapper around other components that rely on userStore data. In case our default userId is wrong we will get fallback to this component with canceling other requests if they are still in progress. src/App.tsx And this is how we are wrapping components that rely on data. Here we are assuming that all of the UI relies on the user to be logged in, and once we are putting correct keys - the full data will come up. At some point your users may want to log out from your service, so don't forget to let them. A simple function that removes you from the service would work just fine. We already defined function setUndefinedUser all we need to let some button trigger it. Let's have this button right under user details. Login and signup forms are usually the first screens your users faced if the user is not found. You may have them manually crafted or generated by some package like aws . The logic for these screens would be as follows: Login flow As you can see these forms are sharing some logic with our Authentication. Full implementation for them would deserve a separate post so we wouldn't describe them fully here. When building a public application you may have a lot of functionality shared between random users accessing your app or logged in user who is looking for the same page. Let's build an example of a component that has a difference. This component would have a condition on what to show depending on the state. You could split them into different pure components or keep in the one, absolutely up to your decision but overall it would be similar to the next component: src/user/ExampleExtraInfoWhenLoggedIn.tsx This component would render only the first name if we are logged in. After login, we will see where this person is working. There are no specific cases to have extra security problems with React. All of the restrictions touching WEB and browser connection to a server as - "You should prefer secure protocol" and "Don't include viable secrets within your FE code". HTTPS As https is pretty a standard over the internet it shouldn't be too hard to migrate your current API to secure version. Secrets on another hand still could be found in dark edges of your FE app. Encryption Some authentication could be implemented with thinking - It is harmful to pass bare passwords to back end and validate there. This approach leads to implementing encryption on FE and opens your app to pass the hash attack. Feel free to pass passwords barely over https, it will do all the work for you. Logging In your FE app, you may have logging included so you can monitor all critical events to your system after some time. How is your system used, what is the user behavior? And at some point, you may have leaking personal data to your logging system, especially for passwords make sure you are not passing it anywhere. And this not comes to passwords, but to any personal data, you may store for users. Growing your application you might want to make sure your users are getting relevant page/information each second of usage. Things like changing your account in any way that changes the behavior of your app. We can think of situations like: Fortunately, we have technologies like Server Side Events, WebSockets that we can use to sync all of our UIs to a state on the back end. With HTTP/2 technology there is no need to have a full WS server to be in sync with the back end. Let's consider our internal API to have next endpoints: With these features, we are simply implementing a pubsub approach where we add a topic on login, remove the topic on logout and subscribing on eventstream. Once we see our user logged out from different tab we can send a message to all registered tabs saying they are not valid anymore. api/index.js src/user/loadUserByToken.ts With these functions on Front End, we are subscribing to the current user if we have logged out on different tabs. Once we receive a message with logout we can update our local state and update UI. I would say it is a good question to discuss with the product team. For UX we should ask users to log in as less as possible, on the other side for security we want to make sure that all actions that users made are really their action. Let's divide the app into 3 levels of graduation: So depending on your application security level, you can pick respectively time to live for your creds. We've touched authentication, authorization, and approaches on how to implement them with React. React gives us the ability to implement all authentication methods pretty easily and inject it in our code following code structure and general architecture. If you want to follow up with more to read

This article guides you through the ins and outs of building your first Rust server. We're going to start from scratch and get to a server that greets you based on a route parameter.The Rust language has been gaining tracking for a lot of reasons in the last few years. One of them is the excellent performance and strong high-level constructs provided by Rust's zero-cost abstractions paradigm. Safety and efficiency are traits expected from all Rust frameworks. You might think that safety and efficiency is something you want from your next webserver application. You might also think Rust language, being lower level than our usual web server go-to languages, might be complicated or convoluted. That's where the developers of Rocket come in. They wanted to marry developer ergonomics to the benefits coming from the language itself so you have no choice but to choose Rocket as the web framework for your next project. We're starting from scratch, installing rust and rocket and building a server that greets you. The intention here is to introduce the Rocket framework for beginner Rust developers and show the door of web applications in the Rust language. First thing first: we need to get Rust running. I said we're starting from scratch and I meant it. To get started with our project, we need rustup and cargo. If you already have Rust installed in your system, you can skip this section. Rustup is the Rust toolchain manager. It's used to install and update the compiler and plug-ins like the official formatter and the official language server. Cargo is the Rust package manager, used to manage projects and dependencies. To get them both properly installed, follow these official instructions . These installers are very friendly to beginners and you should be done in no time. To verify it's all up and running type rustup --version and cargo --version . If you see their versions, we're good to go. Here's an example of my current outputs. Now having rustup and cargo working, we can start our project. Cargo has a handy method to get us started: cargo new --bin rusty-greeter . This command will create a new folder containing an executable project called rusty-greeter . Getting inside the project and running cargo run should execute the project, which will consist just of a Hello World print for now. Next, we're going to install the rocket package . If you're tired of all the setup, bear with me for just one more section. The project should contain an auto-generated Cargo.toml file. The required packages are declared there under the dependencies bracket. That means we want to add the rocket crate with the particular 0.4.4 version to our project. One more thing though: the rocket crate requires the nightly compiler to run, so we need to tweak one more option with the rustup override set nightly command. After that, we can run cargo build to see if it's all working fine. I removed the multiple "Downloaded" and "Compiling" lines from my output, but if you saw something like the above output you're ready to go! All right, the setup is done and solid. We want to have an example GET endpoint that sends from the server a "Hello World" string, just so we know it's all working. Our whole code will be written on the main.rs file, which should also have been auto-generated by cargo. Open up the file in our favorite editor and replace its contents with this. Let's break down this code, which is the core of the rocket application. This line is required by rocket to compile. It's a kind of declaration to the rust compiler what kind of experimental features we want to enable on our project. Don't think about this line too hard, it's just required by rocket currently so we do it and move on. This line just imports some functions from rocket to make our code cleaner. The first one, get , is a macro that defines a GET route. The second one, ignite , is the function that creates the rocket application instance. The last one, routes , is a macro that groups all our routes so they can be bundled into the application. Don't worry about understanding them all now, just pay attention to how they are used in the code. We're using the get macro along with a regular rust function to define, respectively, a route and a handler for it. This bit of code is what the route is and does: the request of a GET on the /greet path will return a "Hello, world!" string. Finally, the regular Rust main function is populated with the ignite , mount and launch function calls, which are just what rocket needs to start running. The important parts of this code are: the "/" string, which is the root path of the server; and routes macro, which should just list all routes in our server. We have all we need to see the first response from our server. To run the server with the current code, just run cargo run . This command builds the project if needed, so don't worry about building it yourself. After a successful compilation, you should see something like this. That's awesome! You can already see it's all running and with some emojis to make our day better. So how do we try it? You can just open up http://localhost:8000/greet in your browser or use an http client to try it from terminal. Here's an output from my favourite one. We already have the greet endpoint that greets the world, and all the setup that comes with it. We're half-way there now, we just need to take a parameter so we can greet you instead of the world. Thankfully for us, Rocket makes it easy to do so. Adding a router parameter to a route in Rocket requires no more imports than what we already have, we just have to pass an extra parameter to the get macro and take the parameter in the function handler like so. Let's once again break down the differences here. Where we previously had the /greet string literal, we now have a /greet/<name> . This just tells Rocket we are expecting something to follow the "greet" on the route path, and we want that something to be named "name". Then we take that "name" as a parameter on the handler, limiting to String s only. The Rocket framework will make sure only Strings pass into the handler. We also replaced the previous &str return type for a String one, which just means we're going to return a new entire string instead of a literal one. Lastly, this format macro call constructs the response we want from the parameter. This macro is very handy for simple string manipulation as we're doing right now. You are probably getting the hang of it already, but we need to stop running the previously running server (a control+C should suffice) and run it again. Unfortunately, Rocket does not provide us with an automatic code reload. After a new cargo run , we should see this again. Also again, we can hit it up on the browser at http://localhost:8000/greet/Lucas or with an http client, which will output something like this. You might be wondering so I'm just going to confirm it. I'm Lucas, that's why I tested with my name. I want to be greeted, just like you. If you're curious, you might have tried the previous example, without the /<name> parameter, only to find out we broke it. On the browser, it will show an error page. It's not found! This happened because we told Rocket that the name should be a String. Rust is very strict on its typing system so if told it's a String, it won't accept anything else. Since we want to support both the "Hello World" and the "Hello Lucas" paths, what should we do? It's surprisingly simple. If we want both behaviors to be present, you just have to write them both as two separate routes. That's what you're main.rs will look like when totally ready. There's a couple routes now, with both behaviours. They should have different function names, so Rust can tell them apart, and they should both be added to the routes macro. Re-running the server again with cargo run we can see they both are working! We made it, we have an up-and-running Rust server with a greeting route! Reaching here, you learned a couple of things. Of course, this is just an introductory post to servers in Rust. The intention here was to just break the ice and show that Rust can have good developer ergonomics even with higher-level applications, like webservers. Rocket paved the road and we walked it together. If you want to keep the learning going, I'd suggest you to start getting more complex with the webserver. Try to answer some of these questions while you keep learning Rocket and Rust. The Rocket documentation will be an invaluable help on your learning, but just by writing it yourself, you'll get familiar with the concept. I hope I have helped to get you started, thanks for the reading!