What’s new: upcoming changes to the REST APIs with Flask and Python course

[jslvtr]

Note: this is a long post, I've been thinking about the stuff here for years. I'd love to hear your thoughts, opinions, and feedback!

---

A few years ago we wrote and recorded one of our most popular courses: “REST APIs with Flask and Python”. With it, we’ve helped tens of thousands of students get started with backend development with Flask.

However, in these few short years, three very important things have happened:

1. Technologies have evolved. Flask reached v1 and then v2, some extensions have become deprecated, and other extensions have been created.
2. We’ve received hundreds of pieces of feedback, including application feedback and suggestions for new content.
3. Our course-making abilities have improved. We’ve made a number of other courses since this one was produced, and we feel like now we can do a better job!

In this discussion piece, I’ll outline what we’ve decided to change in the second version of the course (I’ll call this v2 from now). I’ll also mention some things that we’re still deciding and that we’d like your input on. Finally, I’ve also got some practical house-keeping updates that will improve the course-taking experience in v2.

New updates in v2

Updating Flask to v2

One of the main things that prompted a complete re-record of this course was that Flask reached a stable version in 2018. At that point, not much had changed. But since then, Flask has seen a more intense update cadence, recently reaching v2. Although not much has changed in terms of what the course covers, there are small differences.

One of the main ones are some new async functionality, which we will cover and compare with other libraries such as FastAPI, Sanic, and aiohttp.

Another change is the shortcuts for route definitions. Now, instead of this:

@app.route("/form", methods=["POST"])
def submit_form():
    pass

We can write this:

@app.post("/form")
def submit_form():
    pass

There are other updates to Flask which we will try to include in the, including:

• Multiple changes to send_file for file downloads.
• Nesting blueprints.
• Using the flask executable instead of running through the python command using a run.py file.

More database relationships and API implementation

In v1 of the course, we built a REST API project that mimics a supermarket backend: there are users, stores, and items. There was a database relationship between stores and items (one-to-many).

Many students rightly mentioned that many-to-many relationships were not covered in the course. That was because the course was already getting quite long, at 17 hours. However, almost every application will use them, so we will include them in v2.

Deployments to AWS instead of DigitalOcean

In v1 of the course, I opted to go with DigitalOcean instead of AWS or Google Cloud because of two main reasons: it was easier (for students and for myself), and I’m not a big fan of either Amazon or Google—they both have way too much power in terms of their hosting market shares.

Things haven’t changed at all since then. In fact, they’ve gotten worse. But maybe because of that, developers just have to know about AWS. We can't justify teaching about backend development without including AWS.

That’s why, even though I do this through gritted teeth, we’ll be covering AWS in the course instead of DigitalOcean. We’ll use EC2 for server provisioning and RDS for databases. We're still considering covering file storage in the course. If we did, we would use S3 for that.

We’ll also cover Heroku for those of you that have enough money and not enough time to worry about deployments. Heroku is definitely much more expensive, but it’s also much easier. Also, the Heroku free tier is good for students who want to showcase their projects but don’t have any production load.

Greater focus on API design and documentation

When you’re developing a REST API, some of the most important questions are:

• What is this going to be used for?
• Who is going to be making requests to it?
• What are some technical and non-technical requirements?

That’s something that we want to cover in more detail: planning and implementing a REST API based on real-world use, rather than just as a project that has been planned for you.

In v1 of the course, we used Postman to create collections of requests to the API, and then we wrote documentation on those requests. This is simpler than writing documentation by hand, but lately I’ve been feeling that it’s a bit limiting.

So in v2, we’ll give a bit more focus to writing the documentation manually, as well as integrating Swagger into the API that we develop.

Password encryption

There is something that you just can’t not do: encrypt user passwords. In v1, we didn’t encrypt passwords (although we did write multiple guides on the subject and linked them in multiple places of the course).

In v2, we will make sure we never even leave the door open to not encrypting passwords.

Writing tests with Python and less reliance on third-party tools

Postman is great and makes our life much easier. It helps organise our manual testing, and its automated testing functionality can be really helpful.

If we teach students to only write tests using Postman, especially if that’s the first kind of test they write, they may always lean on that in the future even when a different kind of testing would be more appropriate.

We feel that writing automated tests alongside your code, without reliance on third-party tools, is more reflecting of what happens in the real world. That’s why in v2 we will cover writing automated tests using Python instead.

We will still use third-party tools to do manual testing, as anything else would be borderline masochistic. However, we will try to avoid depending on any particular feature of the third-party tool. That’s why we’ll be using both Postman and Insomnia REST Client when developing the course, and make sure that everything we do can be done with both.

Changes we’re still thinking about

Flask extensions for REST API development

Flask-RESTful is one of the simplest extensions for REST API development with Flask we’ve found. At its core, it lets us easily map classes and their methods to API endpoints:

class ItemResource(Resource):
    def get(self):
        return {"message": "An item."}

That, with some more code to register the class with the Flask-RESTful extension, can give us an endpoint like /item. When accessed with a GET request, it’ll give us a JSON representation of the dictionary it returns.
It adds a bit of abstraction on top of Flask, which I find helps with speed of development.

That’s really everything it does! So although it hasn't received meaningful updates in a long time, I'm not sure it really needs them.

It does make you wonder though, if there isn’t another extension that can be just as simple, but also give you more as your application grows. We’re looking through community extensions, such as Flask-RESTX, to try to find something better.

Flask-RESTX is a little bit more complicated, but it exposes that complexity incrementally. As far as we can tell—before having researched this in depth—using Flask-RESTX can be just as straightforward as using Flask-RESTful, but it can also do more if you want it to.

Added functionality includes:

• Integration with marshmallow for loading and dumping, which also makes it easier to define what arguments an endpoint should receive.
• Integration with Swagger without much boilerplate, as a lot is inferred from the code.
• Documentation which describes a lot of what you can do, so there’s potential for students to learn more about this library.

For these reasons we’re considering using Flask-RESTX instead of Flask-RESTful. If you know of any other libraries which are still being maintained, and aren’t overly complicated or prescriptive in how code should be written, please let us know below!

Docker

Docker--and containerization as a whole--is another technology that has taken over the world by storm.

Containers help with running applications in the same environment no matter which stage of deployment they're at. They also simplify the deployment process once it's been set up.

We haven't covered Docker before because there is a lot to know about it, and we wanted to keep the course focused on REST APIs with Flask and Python. We felt that explaining Docker to beginners in this course would split the focus and require a lot of time.

We've thought about a few options, but none of them satisfy us fully:

• Don't cover Docker at all.
• Cover Docker fully, from zero knowledge, to deployment.
• Assume the student knows a bit about Docker (or has other ways or learning about it), and just cover the deployment of Flask apps using Docker.

The last option is the most appealing, because it allows students to learn about Docker with another guide or course, but still includes how to use Docker for our purposes.

What do you think? Would something like that be sufficient for a REST API course, in your opinion? Have you got any thought about this?

Celery

Celery is a great technology for offloading work to another Python process so we can keep the API running while something's happening in the background. Also, it has scheduling abilities so we can run functions periodically instead of relying on cron jobs or background threads.

It's something that many students have asked for, and initially we thought about creating a completely separate course just for Celery. However, even lately on our internal Teclado projects, we've felt the need of relying on Celery or similar background scheduling technologies.

REST APIs and Celery are a great match, so we're open to at least covering some practical uses of Celery in this course.

Again, if you have any thoughts or opinions on this, we'd love to hear them.

Other topics

Are there any other topics, libraries, technologies, or anything else that you'd like to see in this updated REST API course? (please, don't say Django).

We're all ears! Also, if you have any material (code, guides, articles, tutorials) on the matter, share them with us! And if you want to write some, get in touch. We'd love your contributions.

Changes to the structure of the course and this repository

The last thing to talk about is the course-taking experience.

Over the last few years we’ve gone from making courses purely on video to including more and more text-based content. There are two main reasons for this: it’s much easier to keep up to date, and it’s much easier for students to scan it, copy from it, save it, or otherwise reference it in the future.

Video-based courses are (I would say) much better for the first time you go through them, especially for students with less experience. But when you want to go back to something you watched months ago, text makes it much easier.

That’s why in our latest courses we’ve tried to include both video and text. This course will be no different.

Every video lecture will have a page in our e-book with either a transcript or at least some notes and the code that was written in that lecture.

We’re hoping that when we find small errata or new small updates appear, we can make them to the text content while making small changes to the videos. When there are larger updates, we can re-record the videos then.

[markmjm]

I do recommend adding section related openid (Oauth + openid) to the course. Today, most folks works for company's with some sort of SSO or other form of id. Covering this subject is important

[jslvtr]

Thank you for this suggestion! We do have a section on this in the Advanced REST API Course (we do log in with GitHub). It would be good to include OpenID though for SSO 🤔

Is it something you've got any experience with? I've not had the chance to work with SSO at all, so I don't know how to go about it!

[ryangorden]

I like the ideas you have. Some thinks I would like to see oauth authentication, docker, deployment( AWS/Azure), Kubernestes if possible, and password encryption, terraform. Database that cloud based (AWS/Azure) and if possible app would use micro services architecture. My two cents.

[lawtrea]

It will have to be web app that includes the below: step by step building of an app using Python,
React, Flask, Postgresql,
Redux, Github, rabbitMQ, CircleCI, S3, Cloudfront, Terraform, Heroku, Slack,
github for error reporting, Docker & Sentry."
other than it is the same old kind of just python API tutorials

[gtbulacan]

That's a Great idea but I think it would be better if he will going to build your request as new courses like Python Real World Projects, I love this kind of training from him.

[jslvtr]

This is a very precise set of technologies! The course is specifically about REST API development, so no JavaScript, Flask, or Redux. We also won't integrate with Slack specifically. Not sure what "github for error reporting" means, can you elaborate?

It would be good to implement some sort of logging though! Sentry or Papertrail are two options we're looking into.

[andersrmr]

• Excited about AWS for deployment -- as it is the standard. Thumbs up on covering use of s3 for file storage
• Like the plan to increase focus on API design and documentation. Would recommend RESTX instead of RESTful. Isn't RESTX basically an upgrade from RESTful? I'm using swagger capabilities of RESTX on a project currently.
• YES! to Docker. Something I haven't spent enough time with and want to learn better. Probably ok to point to a different resource to learn it from step 0.
• Also agree that password encryption is a must.

[jslvtr]

Thank you very much! Glad to get your thoughts. File storage is definitely something we get asked about a lot. We covered it in the Advanced REST API Course, but storing only in the filesystem. It's a bit limiting (especially if you're using Docker + automated deploys), so going with S3 sounds is better.

Do you have any public repos where you use RESTX? Would be keen to get my eyes on some actual application code!

It sounds like we're going to be including Docker in the course in some way. Maybe a written guide + practical advice on deploying with it, or something like that. We don't really want to teach it from scratch.

[andersrmr]

There is a nice example here that is linked from the documentation. My issue right now (new to Flask) is that it's taking me way too long to figure out the input/output model documentation here.

[Adi0687]

I get that this is a free upgrade for current students? Or do we have to buy it again?
What is the timeline for the upgraded course? I bought the course a while ago and have just started, do I wait for the upgrades, or continue? If the upgrade will be in the coming week, will be worth waiting for it!
Excited about the upgrades, especially for the AWS part, because its practical and is what is actually used!
I would love to see the 3rd option in the Docker section above!
Thanks

[gtbulacan]

I think the subject was "upcoming changes to the REST APIs with Flask and Python course", meaning he will going to update the old one. Meaning the current students will benefits to this new changes. Honestly I bought this training to my other Udemy account but I still not yet started it :-) hahahaha. I'm too lazy just buying all of his courses during sales to support him, I like his attitude and the way he communicate to his students. Another reason is I become comfortable to Django and no time to study Flash.

[jslvtr]

This will be a free upgrade to the existing course. Upgrade timeline is a bit further out than 3 months, I'm still finishing up another course update first. I think the course as it is will still be helpful (and everything in the current course is very much valid), so I'd say just go for it!

Later on, when we release the update, it will come with an e-book that you can go through to learn some of the new stuff. That will be especially helpful if you already have knowledge of Flask and REST API development.

@gtbulacan you're too kind 😄 thank you for your support! It really means a lot!

[Adi0687]

Thanks for your reply @jslvtr , i should get to it asap!

[gtbulacan]

Nice! Good work for updating the old courses. Jose, do you have a plan to create Django courses?
Please let us know, thanks.

[jslvtr]

We started planning a Django course, but it hasn't gone anywhere yet I'm afraid... I don't have professional experience with Django so I've put it on pause for now. I'm afraid, no concrete plan to release a Django course just yet.

[codersteinersky]

Agree with your option 3 on Docker just use it explaining only what's relevant but let other courses, books address it in full.

[jslvtr]

Thank you for your thoughts! I'm glad we're in agreement!

[codersteinersky]

I am very curious about whether this will be an update to your existing course as @gtbulacan mentioned or a new one. Also, is it something you hope to release on Udemy in the next 2-3 months or might it be longer?

[gtbulacan]

Yes, I think many author doing this kind of approach like Tim Buchalka, Andrei, Max and many more because I enrolled over 100 courses in all of my Udemy accounts. I created multiple accounts just for fun :-). If he will create new course, I think he will mention it above not update "What’s new: upcoming changes to the REST APIs with Flask and Python course". For the timeline maybe 2 to 3 months or more not sure lets wait Jose to give us an update on twitter.

[jslvtr]

Yep, this will be an update to the existing course. It probably will be a bit longer than 3 months though, still finishing up another course update first.

[sqpusher]

This is great! I totally agree with you on each point. With coverage of AWS, Docker, Celery you're literally creating a real bootcamp for backend positions! 👍 And yes, text over video for code and technical stuff is the way to go! Great job!

[jslvtr]

Thank you very much @SagittariusA ! That's the plan! Get you started with all the major technologies so you can really take it to the next level with any of them!

[bertramdryan]

It would be really nice to see websockets covered in this course. Or maybe in an advanced course. This is something often NOT covered in tutorials or if it is, especially for python frameworks, it isn't done in a well put together straight forward way. And live data is very often a request of a client or employer.
TestDriven IO attempts to do this in Django, and it is ok, but still very confusing, even for an experienced developer.

This doesn't need to take up a lot of time, but I feel it is pretty important. Microsoft's tutorial for SignalR is very simple, not long at all, can be setup with ran within a few minutes.
I have seen that Flask does have some web socket libraries, but I have never seen them demonstrated. My 2 cents.

[jslvtr]

Hey! I'm looking into websockets. It's not something I've had to use before, but I can see why it might be interesting. I'll do some more investigating, and then publish what I find out here in another discussion! Thanks Ryan.

[bertramdryan]

I don't know if it is too late to look at this perspective, I have been doing professional software dev since 2013, and only 1 place I've done work for has used AWS. While IT IS widely used, I believe it is also very common so see Azure being used. So, why grit your teeth over Google or Amazon. Perhaps Azure would provide the same teeth gritting experience, but it would be very cool to see a Flask app being deployed there.

[sqpusher]

I guess it heavily depends on which country and industry you work in. In Germany, a lot of companies still use on-premise ADs and run VMs, so for them anything "Cloud" is super futuristic and difficult to comprehend. But then young companies generally choose AWS for a huge community and Google for, well, Kubernetes mainly I guess 😄

[bertramdryan]

@SagittariusA I really wish more companies would use on-premise hardware. Unless the organization is massive. I've work with clients with less than 300 employees with a few sites in various states, and yet they see fit to pay Microsoft or Amazon $2000+ a month to host and do IT. While it might seem like a saving than to have a dedicated DevOps person, I think too many things are outside of the control of IT managers. The savings isn't worth the trouble or downtime.

[pftp-jz]

@bertramdryan i think its a timing thing, its easier to start with 2~5 devs and achieve scalability without DevOps using cloud, when a company grow and the cost of cloud becomes just too high a transition start to vms and finally to on-premise, hiring a DevOps day 1 to run a service for 1000 users isn't worth, and if you are in USA paying 2k a month for a service that solve all your problems still way cheaper than hiring someone to do DevOps

and i agree with Azure being a good choice, the costs are not the most attractive, but the service is really good

[jslvtr]

That's definitely interesting. I've not tried Azure nor do I know much about it, but I'll take a look. There are a couple things I'm looking for with the new dev ops material:

• Usefulness (of the material, i.e. how widely used the technology is)
• Chances to practice (AWS has a good free tier for students, I'll look into this)
• Ecosystem (gritting, but important nonetheless)
• Ease of use so students can actually go through with it

[petarpetarpetar]

To add to @jslvtr's comment, Azure also has a free plan for students. I've been using it three years ago (for about 2 months) when they suddenly canceled, what should have been, 2 years free plan. No explanation was given nor they answered to any of my emails. I know a few other students that have had the same experience. At the time I didn't give it much though but I could investigate this further if needed.

[vladdg-dev]

Even if students now a little bit about Docker or nothing at all, I think it should be covered in the same way as venv and pipenv was. Just getting a brief idea of what it does, why it does and how it does, should be sufficient for the majority of the students to get the feel for it, and explore more by themselves. Starting from this idea, it would be nice to have a series of blog posts covering Docker and then DevOps like in the 30 Days of Python.

[jslvtr]

I agree, I don't think we can go all out on Docker material, but in the course covering it quickly and practically seems like the best (only?) option.

Writing some blog posts, or even a separate course just for Docker, could be a very good idea too! Something to add to the roadmap for sure.

[TLVroadrunner]

Hi Jose, Can you please include a review of how Flask handles multithreading? When use of libraries such as 'Waitress' is needed. Thanks!

…

On Tue, Jul 6, 2021 at 1:56 PM Jose Salvatierra ***@***.***> wrote: *Note*: this is a long post, I've been thinking about the stuff here for years. I'd love to hear your thoughts, opinions, and feedback! ------------------------------ A few years ago we wrote and recorded one of our most popular courses: “REST APIs with Flask and Python”. With it, we’ve helped tens of thousands of students get started with backend development with Flask. However, in these few short years, three very important things have happened: 1. Technologies have evolved. Flask reached v1 and then v2, some extensions have become deprecated, and other extensions have been created. 2. We’ve received hundreds of pieces of feedback, including application feedback and suggestions for new content. 3. Our course-making abilities have improved. We’ve made a number of other courses since this one was produced, and we feel like now we can do a better job! In this discussion piece, I’ll outline what we’ve decided to change in the second version of the course (I’ll call this v2 from now). I’ll also mention some things that we’re still deciding and that we’d like your input on. Finally, I’ve also got some practical house-keeping updates that will improve the course-taking experience in v2. New updates in v2 Updating Flask to v2 One of the main things that prompted a complete re-record of this course was that Flask reached a stable version in 2018. At that point, not much had changed. But since then, Flask has seen a more intense update cadence, recently reaching v2. Although not much has changed in terms of what the course covers, there are small differences. One of the main ones are some new async functionality, which we will cover and compare with other libraries such as FastAPI, Sanic, and aiohttp. Another change is the shortcuts for route definitions. Now, instead of this: @app.route("/form", methods=["POST"]) def submit_form(): pass We can write this: @app.post("/form") def submit_form(): pass There are other updates to Flask which we will try to include in the, including: - Multiple changes to send_file for file downloads. - Nesting blueprints. - Using the flask executable instead of running through the python command using a run.py file. More database relationships and API implementation In v1 of the course, we built a REST API project that mimics a supermarket backend: there are users, stores, and items. There was a database relationship between stores and items (one-to-many). Many students rightly mentioned that many-to-many relationships were not covered in the course. That was because the course was already getting quite long, at 17 hours. However, almost every application will use them, so we will include them in v2. Deployments to AWS instead of DigitalOcean In v1 of the course, I opted to go with DigitalOcean instead of AWS or Google Cloud because of two main reasons: it was easier (for students and for myself), and I’m not a big fan of either Amazon or Google—they both have way too much power in terms of their hosting market shares. Things haven’t changed at all since then. In fact, they’ve gotten worse. But maybe because of that, developers just *have* to know about AWS. We can't justify teaching about backend development without including AWS. That’s why, even though I do this through gritted teeth, we’ll be covering AWS in the course instead of DigitalOcean. We’ll use EC2 for server provisioning and RDS for databases. We're still considering covering file storage in the course. If we did, we would use S3 for that. We’ll also cover Heroku for those of you that have enough money and not enough time to worry about deployments. Heroku is definitely much more expensive, but it’s also much easier. Also, the Heroku free tier is good for students who want to showcase their projects but don’t have any production load. Greater focus on API design and documentation When you’re developing a REST API, some of the most important questions are: - What is this going to be used for? - Who is going to be making requests to it? - What are some technical and non-technical requirements? That’s something that we want to cover in more detail: planning and implementing a REST API based on real-world use, rather than just as a project that has been planned for you. In v1 of the course, we used Postman to create collections of requests to the API, and then we wrote documentation on those requests. This is simpler than writing documentation by hand, but lately I’ve been feeling that it’s a bit limiting. So in v2, we’ll give a bit more focus to writing the documentation manually, as well as integrating Swagger into the API that we develop. Password encryption There is something that you just can’t not do: encrypt user passwords. In v1, we didn’t encrypt passwords (although we did write multiple guides on the subject and linked them in multiple places of the course). In v2, we will make sure we never even leave the door open to not encrypting passwords. Writing tests with Python and less reliance on third-party tools Postman is great and makes our life much easier. It helps organise our manual testing, and its automated testing functionality can be really helpful. If we teach students to only write tests using Postman, especially if that’s the first kind of test they write, they may always lean on that in the future even when a different kind of testing would be more appropriate. We feel that writing automated tests alongside your code, without reliance on third-party tools, is more reflecting of what happens in the real world. That’s why in v2 we will cover writing automated tests using Python instead. We will still use third-party tools to do manual testing, as anything else would be borderline masochistic. However, we will try to avoid depending on any particular feature of the third-party tool. That’s why we’ll be using both Postman and Insomnia REST Client when developing the course, and make sure that everything we do can be done with both. Changes we’re still thinking about Flask extensions for REST API development Flask-RESTful is one of the simplest extensions for REST API development with Flask we’ve found. At its core, it lets us easily map classes and their methods to API endpoints: class ItemResource(Resource): def get(self): return {"message": "An item."} That, with some more code to register the class with the Flask-RESTful extension, can give us an endpoint like /item. When accessed with a GET request, it’ll give us a JSON representation of the dictionary it returns. It adds a bit of abstraction on top of Flask, which I find helps with speed of development. That’s really everything it does! So although it hasn't received meaningful updates in a long time, I'm not sure it really needs them. It does make you wonder though, if there isn’t another extension that can be just as simple, but also give you more as your application grows. We’re looking through community extensions, such as Flask-RESTX, to try to find something better. Flask-RESTX is a little bit more complicated, but it exposes that complexity incrementally. As far as we can tell—before having researched this in depth—using Flask-RESTX can be just as straightforward as using Flask-RESTful, but it can also do more if you want it to. Added functionality includes: - Integration with marshmallow for loading and dumping, which also makes it easier to define what arguments an endpoint should receive. - Integration with Swagger without much boilerplate, as a lot is inferred from the code. - Documentation which describes a lot of what you can do, so there’s potential for students to learn more about this library. For these reasons we’re considering using Flask-RESTX instead of Flask-RESTful. If you know of any other libraries which are still being maintained, and aren’t overly complicated or prescriptive in how code should be written, please let us know below! Docker Docker--and containerization as a whole--is another technology that has taken over the world by storm. Containers help with running applications in the same environment no matter which stage of deployment they're at. They also simplify the deployment process once it's been set up. We haven't covered Docker before because there is a lot to know about it, and we wanted to keep the course focused on REST APIs with Flask and Python. We felt that explaining Docker to beginners in this course would split the focus and require a lot of time. We've thought about a few options, but none of them satisfy us fully: - Don't cover Docker at all. - Cover Docker fully, from zero knowledge, to deployment. - Assume the student knows a bit about Docker (or has other ways or learning about it), and just cover the deployment of Flask apps using Docker. The last option is the most appealing, because it allows students to learn about Docker with another guide or course, but still includes how to use Docker for our purposes. What do you think? Would something like that be sufficient for a REST API course, in your opinion? Have you got any thought about this? Celery Celery is a great technology for offloading work to another Python process so we can keep the API running while something's happening in the background. Also, it has scheduling abilities so we can run functions periodically instead of relying on cron jobs or background threads. It's something that many students have asked for, and initially we thought about creating a completely separate course just for Celery. However, even lately on our internal Teclado projects, we've felt the need of relying on Celery or similar background scheduling technologies. REST APIs and Celery are a great match, so we're open to at least covering some practical uses of Celery in this course. Again, if you have any thoughts or opinions on this, we'd love to hear them. Other topics Are there any other topics, libraries, technologies, or anything else that you'd like to see in this updated REST API course? (please, don't say Django). We're all ears! Also, if you have any material (code, guides, articles, tutorials) on the matter, share them with us! And if you want to write some, get in touch. We'd love your contributions. Changes to the structure of the course and this repository The last thing to talk about is the course-taking experience. Over the last few years we’ve gone from making courses purely on video to including more and more text-based content. There are two main reasons for this: it’s much easier to keep up to date, and it’s much easier for students to scan it, copy from it, save it, or otherwise reference it in the future. Video-based courses are (I would say) much better for the first time you go through them, especially for students with less experience. But when you want to go back to something you watched months ago, text makes it much easier. That’s why in our latest courses we’ve tried to include both video and text. This course will be no different. Every video lecture will have a page in our e-book with either a transcript or at least some notes and the code that was written in that lecture. We’re hoping that when we find small errata or new small updates appear, we can make them to the text content while making small changes to the videos. When there are larger updates, we can re-record the videos then. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#32>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKS4RBIZ3RMFJMVC4YPUYDTWLOPVANCNFSM474KMPDQ> .

[jslvtr]

Hey, that's a great idea! I'll see how/if we can expand on it instead of just relying on gunicorn or uwsgi. Thanks!

[bhattraideb]

Hi, it would be great if you can include a flask blueprint with a real-time project instead of a simple CRUD operation.

[YazanSneneh]

when this update is coming ?

[heyaco]

Yes I'd like to know too. Any update on the new videos?

[AnkitJha16]

Hi @jslvtr ,

Nice to hear we are getting updates on our existing courses...
Thumbs up for password encryption , Docker ,Celery , and esp AWS....

However I would want you to take the second way of delivering content i.e
---> Cover content fully, from zero knowledge, to deployment.

It helps to remain in sync with the project we are working and better able to relate it.. Even if you cannot give video....text would also be equally helpful....

I have one question though ..whenever you give any updates to any course how can we be able to distinguish between the version 1 content and later versions content. Also some documentations will be helpful to us like why we had to upgrade the content (like version upgrade of libraries and what part of the code snippet we used earlier and how we are coding now with the help of upgraded version libraries and its potential benefits ) .These text would really help us to understand what has changed...

Looking forward to your upgraded content..

[haydenlingle]

Any updates on timeline for this course refresh?

[jslvtr]

Hey Hayden, we're currently working on updating the project that we build in the course and adding these new features to it. Once that's done, we'll get to writing the new content. After that, comes recording.

I don't have an ETA yet on the course being fully updated 🤔 but I estimate (or hope!) around 6 months.

[haydenlingle]

@jslvtr Is this ever going to come out?

[jslvtr]

@haydenlingle it will! It's actually almost all uploaded on Udemy, just missing one video. I didn't have time to get to it before leaving, and I'll be back on Sep 21. I'm expecting to release the changes before the end of the month!

[jslvtr]

@haydenlingle the course is now released on Udemy! 🎉

[cristiantcjti]

Hello @jslvtr , first of all thank you so much for all the hard work and efforts you've put in to create and update this amazing course. Regarding the updates, I will be more than greatful if you add a Celery section to the course. Celery is largely used but it's quite hard to find good courses containing Flask+Celery. I am looking forward to seeing this update. All the best for you and your team @jslvtr.

[johnstanforth]

@jslvtr Just wanted to echo what others have said, thanking you for the effort you've put into this course and especially putting the e-book version online for free. That should be a great intro to people wondering whether the course is right for them, and especially valuable to people in other countries where even the often-discounted course fees are perhaps unaffordable for them. It also helps the rest of us send more people to your great work-- for example, in this Reddit comment I just posted Only suggestion: Maybe make the "Get Course" button in the top-right more noticeable so that people can easily see how to reach the course? Wishing you lots of success with this.