me too, this dude is an angel

I think this has to be one of the best tutorials I’ve ever watched…

Awesome! Thanks for taking the time to share your experience.

Impressive that you finished in one session.

Thank you for the very nice feedback.

Thank you so much for your support and comment. More cool stuff is coming...

Yes, in a future episode we will talk OAuth, probably with Google and/or GitHub as an example.

Thanks for the feedback. On the latest main branch, I put the fix/workaround for SQLx 0.7, which is to set max_connections = 1 for testing. It's not ideal, but it works until they fix the issue. Latest main branch: github.com/rust10x/rust-web-app Also, feel free to join the Discord. Discord: discord.gg/XuKWrNGKpC I am working on episode e02, where we've moved to sea-query and more modql. Work is still underway, but it's the next level and will be the prep for the second episode. Serial testing is required due to the brute-force database reset approach. It could be removed with some work. When to undertake that work depends on preferences/priorities. But it's potentially valid to do in some cases.

This is an interesting topic, and I would love to have a discussion with you about it. If you have time, I would love to chat about this in our Discord: discord.gg/XuKWrNGKpC In short, yes, the application blueprint will eventually have multiple clients inside the ModelManager, but I am not sure we need multiple of them. However, I am definitely interested in discussing the pros and cons.

Great question. Here is a first pass at the answer. I also added this as the first FAQ question. Decoupling the construct that performs the task (i.e., ModelController) from the one that provides the resources (i.e., ModelManager) has the following benefits: 1. Keeps the ModelController design and requirements more focused on its function, which is to perform data changes. 2. Keeping the ModelController construct stateless greatly simplifies "specialization" implementation (see `model::base`). 3. Allows the management of the resources (typically in App State) to evolve separately while minimizing impact on the model controller (and vice versa). In short, this separation of concerns allows both parts to stay more focused on their respective functions and to evolve separately while minimizing how they affect each other. As the application's needs grow, these patterns can evolve, and further separation of concerns may be needed. However, this is a good base to start with, balancing simplicity and future code scalability. Congrats, you are the first in the FAQ: awesomeapp.dev/rust-web-app/#why-distinguish-between-the-modelmanager-and-modelcontroller

Btw, I just updated the answer in the FAQ with the text below. And also, I am planning to do a quick video to go over those points. Let me know if you have an handle (youtube, x, github) you want me to use to refer you (as you want). Thanks again for this great question. I hope it is getting answered: === Anwser - The short answer is because it makes each component much simpler and more focused on executing its core function. - For example, now the ModelControllers do not need any states, and therefore, their design becomes simpler as they are merely a set of functions with some common contracts. - We do not have to worry about ModelControllers' instantiation, ownership, lifetime, or anything of this nature in our design. - So, we know that everything that would be state-related will be passed as an argument in a consistent manner. - And in fact, that goes for the Ctx as well, - And that simplicity allowed us to design the base shared CRUD implementation just as a set of static functions. - Conversely, the ModelManager now can just focus on holding and managing the appropriate resources that might be needed by the various - ModelControllers, irrespective of the specific operations. - Right now, it is a very simple implementation, but it will become richer when we add more client types and database transaction support.

@@JeremyChone wow ! I wasn't expecting such a good response ! it was pretty clear, thank you ! (and you can call me simply kaporos, but you dont have to ahah)

@@kaporos I am making a video about this question. It came up couple of times, and it is an important point.

It's just a code snippet that I bind to ctrl+c. Go to configure snippet for rust language `User/snippets/rust.json` "comment-section": { "prefix": "cc", "body": [ "// region: --- ${1:Section}", "${2}$TM_SELECTED_TEXT", "// endregion: --- ${1:Section}" ], "description": "Comment Section" }, keybinding `User/bindings.json` { "key": "ctrl+c", "command": "editor.action.insertSnippet", "when": "editorTextFocus", "args": { "name": "comment-section" } },

@@JeremyChoneAha! very nice I'll try it out! I'm currently following along with the video to make this project myself and this will be helpful. I really like the insights when it comes to architecture design of a web app.

Those are good questions. I wanted to write the longer answer, but here is a relatively short one: 1) Secure Web Token vs. JWT: In our case, we assume the token is designed for interpretation solely by our system. Different services may exist, but they all belong to the same organization. Hence, we don't need to disclose the algorithm used, as sharing less is preferable. The design also aims to decouple Authorization from Authentication. The token is used to verify identity, but roles, privileges, and other aspects are better managed by an independent API and re-evaluated at the time of request. Roles/Privileges should be transactional, with tokens remaining valid longer than the period suitable for checking roles/privileges. Therefore, roles in JWT are more cosmetic than security-based. In distributed systems where we don't own all the systems, JWT might be acceptable, though many don't share keys. However, one shouldn't fully trust the roles defined in JWT. At its simplest and most secure, a token comprises three essential parts: - The identifier (e.g., username or user UUID), - The expiration time, - The signature, created with minimal information sharing. In summary, while JWT may be useful in a distributed context, in a multi-service system we own, adopting a minimalistic approach with less information sharing reduces the attack surface and enforces transactional access control. 2) Diesel for Migration: Our approach here differs. For large apps, 'Migration' or 'Evolution' (as we prefer to call it) is better managed as a sidecar service, rather than at the web-app level through the Database Driver or ORM. If our ORM or SQLX manages migration within our app code, we must determine which container instance is responsible. Only one instance should update the database schema. This indicates that the web server, typically scaling horizontally, should not be responsible for schema updates. This task is more suitably handled in a sidecar, a dedicated pod/container, and thus does not need to be integrated into the ORM, SQL Builder, or lower-level database drivers like SQL. 3) JSON-RPC & QL: Refer to Episode 02 (kzfaq.info/get/bejne/Y8p9e5yGzt2voZs.html) which discusses SEA-QUERY and MODQL for advanced JSON-based queries (JSON IN and JSON OUT). More exciting developments are forthcoming. You can also view a quick spec I developed on joql.org to see upcoming features (included in the specifications). Hope this makes sense. Our philosophy is not about reusing as many wheels as possible, but rather about using the right ones. Happy coding.

@@JeremyChone thank you for the extended answer

@@JeremyChone Wow, and that was the "short! answer :D 1) Very nice insight on the Secure Web Tokens vs JWT. 2) I'm looking forward to learn how you handle migrations/evolutions in a sidecar service Going through the comment section of your videos to find these answers is definetly worth it!

Good question, and it is something I plan to address in the future. In the meantime, here are a few points to consider: 1) For a small number of API methods, say between 10 and 20, the current approach should suffice. After all, we would need a routing table regardless of the method adopted. Whether we are using macro rules or another strategy, it should work well. 2) As the number increases, it might become necessary to create sub-web modules, each responsible for registering their respective APIs. I envision adopting a builder/plugin approach somewhat akin to the "router" strategy utilized by Axum. 3) Firs I would explore the potential of leveraging the Tower service model to aid in this process. While I am cautious not to unnecessarily complicate the system just to "reuse a wheel," the Tower model might prove to be a good fit. I will investigate this at a later stage. 4) Some time ago, I created a video on constructing an Async Router ([watch here](kzfaq.info/get/bejne/r9WSpq-l2LO0fGw.html)). This might serve as a foundation if the Tower lib is not a fit. The goal prioritizes maintaining simplicity in the system, avoiding overly intricate solutions and focusing on meeting immediate needs. Currently, all RPC handlers can be normalized, as demonstrated, incorporating elements such as context (ctx), multimedia messaging (mm), and parameters (params), which simplifies the system considerably. While I do plan to develop such a design in the future, the existing design is scalable to around 20 methods. Beyond this point, the details become specific to web:rpc implementations, thereby having minimal impact on the rest of the code. I hope this provides some insight into your question.

Sorry for the late answer. Yes, eventually I am going to show how to do nested/join (like project/task relationship). You would do join. For now, you will have to use raw sqlx, since sqlb does not support join yet.

Yes, this is the plan. It will come a little bit later as this will be done via Kubernetes and will have multi service support.

Amazing! Thanks a lot!

The code design approach allows for `Ctx` to be "injectable" into any Axum middleware or handler functions, enabling them to extract information or, eventually, add information to it. Since `Ctx` is designed to be per request, the appropriate Axum construct to use is Request Extractors. States are suitable for application-wide resources, such as the ModelManager (e.g., with some type of database client), and similar components. I hope this answers your question.

I finally took some time to create the Rust10x VSCode Extension and a webpage with information about my VSCode setup. Everything can be found here: rust10x.com/vscode

Okay, this is a very good question, and usually, when we encounter repetitive patterns like this, they are good candidates for consolidation. First, let's clarify what each element is: `ctx` - This is designed to be the request/command context containing user information. Eventually, it will include on-demand PBAC (Privilege-Based Access Control) and other per-command contexts. The aim is to decouple it from the web layer, which will become more apparent in future episodes when we separate the web layer and the core layer (model, ctx, etc.) into their own sub-crate. `ModelManager` - This serves as the "model app state," where we have various clients (DBCon, S3Client, etc.) to communicate with different services. Since all BMC functions take both arguments, we might consider putting them into a single container construct to combine them. However, their responsibilities and usages are different, so the container construct would not have methods specific to sub-elements, allowing us to maintain the separation of concerns. This is why, for the time being, I have kept them separate. Other approaches are also valid as long as they provide a coherent narrative and stand the test of time.

Yes, something changed in sqlx 0.7 that causes this issue when running tests. The trick is to set the DBPool connection maximum to 1 for testing. If you check the latest main repository, take a look at the lib-core crates. When we create the SQLx client, there's a cfg test that sets the maximum to 1. It's not the most elegant solution, but it works and has no impact on production.

@@JeremyChone hello Jeremy, thanks for replying so quickly, you are a blessing, truly

Make sure that in your `.cargo/config.toml` you have the right crate names in the RUST_LOG environment variable. See: github.com/rust10x/rust-web-app/blob/main/.cargo/config.toml

@@JeremyChone thank you!

Oh, this video features a real Model layer that interacts with PostgreSQL. The Rust Axum Full Course serves as a mock store designed to teach the mechanics of Axum. So, I believe this video should answer your question. Please let me know if it doesn't.

It's in the github as ". initial" It's mostly the Rust Axum Full course a little bit preped .

@@JeremyChone thank you

Ok, this is a great question. I plan to create a page on rust10x.com and/or a video to discuss the pros and cons of each approach and explain why we prefer the SQL (e.g., SQL builder) route. In the meantime, here are a few points: - Firstly, the Model layer code is designed to decouple implementation details from the rest of the application code. - Therefore, while the Model layer can utilize an ORM (e.g., Diesel) or a more SQL-centric approach (e.g., sqlx / SQLB), the remainder of the app's code shouldn't need to be aware of these specifics. - We have extensive experience with ORM, going back to our time working with Java, using Hibernate and familiarizing ourselves with JPA in general. - However, even during our Java days, we gravitated towards a more SQL/SQLBuilder approach, akin to JOOQ. - ORMs can simplify the initial stages but may become overly complex as development progresses. - They tend to lock language data structures (like Java classes or Rust Structs) to their respective tables, requiring meticulous attention to ensure perfect alignment between the two. - Although this approach might seem attractive initially, we found that it does not scale well for larger applications (with 200k to 500k LOC). - The intertwining of language types and database table structures and relationships can become a source of complications, causing issues for both elements. - Taking the time to understand SQL deeply and learning how to effectively query data for specific functionalities greatly simplified our system, despite the additional SQL knowledge it required. - We reduced many instances of O(n²) and O(n) complexity to O(1). This improvement was not so much a reflection on the flaws of ORMs but a benefit of abandoning a one-size-fits-all approach, enabling us to optimize our query and data assembly processes. - Indeed, working with raw SQL can also have its own set of problems; it is error-prone and can be tedious, especially when ensuring the use of prepared statements and maintaining track of argument IDs. Moreover, the necessity for order in SQL does not lend itself to composability. - This is where SQL builders, akin to knex.js in Node.js and JOOQ in Java, come into play, offering great composability benefits while staying true to the relational model. - It's crucial to note that the design blueprints at rust10x (encompassing rust-web-app, this one, and the rust desktop app - formerly known as AwesomeApp) are built with a model layer design. This means the choices made here are layer implementation details and should not affect the rest of the code base. - It is a fundamental rule that anyone wishing to read or write to any store should do so through the model layer. - Therefore, developers can utilize this blueprint and employ tools like SeaORM or Diesel without encountering many hiccups. So, in short, I believe that staying closer to the respective stores, be it a database, S3, or Redis, offers better scalability. Moreover, a good scalable design, irrespective of the approach chosen, involves establishing the right application abstraction layer (e.g., the model layer) from the outset. I hope I have somewhat answered your question. I plan to delve deeper into this subject in the future. It's important to note that the blueprint supports both approaches. I personally prefer the one that I believe scales better for our style, but other styles are completely fine too.

​@@JeremyChone Thank you very much for your time by giving so much detail and examples!

Hi, what do you mean by logic layer ?

@@JeremyChone I hope that the database transaction can be started when the model method is called in the business logic code. The logic layer here refers to the place where the business logic code is written

@@JeremyChone Assuming that I have an interface for placing orders, which involves modifying multiple tables (order, order_detail, user, wallet, points, goods, etc.), I need to initiate database transactions to ensure data consistency. Currently, the framework does not involve database transactions. I hope to see this section as soon as possible. Thank you very much.

I am currently undertaking a major upgrade for seamless transaction support. Essentially, the design remains the same, but now you use `mm.dbx()` to execute SQLx commands. Then, you can initiate a connection with `mm.dbx().begin_txn()`, and any subsequent use of `mm.dbx()` for SQL will be within this transaction. This should be quite exciting. Keep an eye on the repository; a big update is coming soon. I'll try to make a video about it. For more information, feel free to join the Discord:

@@JeremyChone Wow, I'm really looking forward to it

I think “menlo” for vscode, and “lato” for video text.

just vscode snippets. Here are some: rust10x.com/vscode

Btw, I finally took some time to create the Rust10x VSCode Extension and a webpage with information about my VSCode setup. Everything can be found here: rust10x.com/vscode

Here is the little extension I made. rust10x.com/vscode If you go to the extension install page, you can click on respository to see the github source.

@@JeremyChone thank you, sir

Good question. My aim is to strike a balance by offering high-quality content for free on KZfaq, while also planning to build a unique learning experience on awesomeapp.dev for production coding (currently just a very simple static website). For now, I have a Patreon page (patreon.com/jeremychone), where any_help == big_help. I've been running my business focused on building Big Apps with Small Teams for some time, and I'm taking a shot at pivoting to share this expertise with a wider audience, rather than just a select group of clients. Only time will tell if this approach will be successful, but if it is, more happy coding!

in my opinion, he should try to make money so that we can get more of these videos!

Ho, interesting, building a Spotify or Reddit clone you mean? That could be interesting once I finished the blueprint. Still many episodes to come to make it full production.

@@JeremyChone Yes! It's what React/ Next usually have as an advantage, as there are lots of tutorials like that which interest people. This might be a chance to bring in more people to the Rust community and maybe make the contribution to this space a lot faster than ever. Again, thanks for these kinds of tutorials, its badass great!

​@@ryz177 Cool, I've considered creating new upcoming startup ideas, but just cloning existing apps could be great. The Rust10x web-app will be well-structured for that purpose. Thanks for the feedback!

Found you answer in these comments. Thanks anyways. Good to know it wasn't on my end and I figured out the solution on my own 😅

Yes, this was something introduced with Sqlx 0.7. I set the max connection to 1 during testing to make it work. I think it's a decent workaround. Not sure why Sqlx hasn't fixed this issue, but it likely only happens in test mode.