Cookiecutter Template

Moving forward
#1

Considering how fast the sanic community is growing (based on number of *s and forks in Github) it sounds logical to start providing the users with some easy way to init their project with some basic wrapper using cokiecutter. This will simplify the process of having to worry about some housekeeping that the developers don’t always have to worry about. It will also ensure some level of consistent project structure. (Especially with all the experienced developers we have here, we can leverage some best practices into this template"

I just started to work on creating a new base reference template that can be used with Cookiecutter to start your sanic project. I was wondering if the community has some suggestions on what features they want to see in it so that I can prioritize them when I add things to it?

Ref: Cookiecutter-Sanic

1 Like
#2

Awesome! I will take a look and give my input. I also want to add to that an “official” docker image. I was also thinking about making a video series. Maybe I will wait until we have a few more items like your cookie cutter template.

#3

I’ve included a basic docker and docker-compose support already. I was also thinking of adding deployment stubs aimed towards aws, gc, cloudfoundry and heroku. This way, one will get the base stub to start with and they can customize it later based on their needs.

And I completely agree that we should have an official docker images in the hub with each release so that anyone who wants to use can just pull that as the base to start.

#4

Nice… We do have sanicframework reserved on Docker hub.

#5

Why tox for python 3.5, 3.6, and 3.7? I feel like generally when you are building an applications (as opposed to a library), you have a requirements in mind and are building to a specific environment. Also, your Dockerfile is set to 3.6 … Maybe this could be a startup question?

Also, I would personally like to see gunicorn as an option and not the only way to run the server.

I see you have auth on the TODO list. What do you have in mind? I realize I am biased on this one, but if you have any questions on sanic-jwt, I am happy to provide you my thoughts/recommendations.

I love the idea of change log and release management. Those are the types of conveniences that I lvoe about kicking off a project with cookiecutter that I don’t need to figure out how I want to set them up. On the other hand, ORMs seems tough. The field is SO open how would you choose what to support?

I see you have a config manager for taking from env variables. What about also providing support for passing from a file, ini, yaml, toml, etc?

#6

tox items I have now are just starting boilerplates. I am going to turn them into a pick list where you get to keep one from the available list of values and it will be setup accordingly.

Turning gunicorn into one of the options to run seems like a good idea as you mentioned. Let me add it to the To Do list.

As for the Authentication goes, I want to have a basic setup in place if the user of the templates so chooses to have it in their code. This way they need not worry about finding out what methods they need, where they need to configure certain components and such. And of course, it will leverage sanic-jwt. I’m a huge advocate for JWT over any other auth mechanism available today.

ORMs like you said is a hard thing, i’ve tried and failed in my attempt to build one at work a while ago. Too many things to worry and handler. However, in this case, the plan is much simple. I just want to enable support for either GINO/peewee/sqlalchemy with a basic example code that user can extend out of.

Enabling support in additional file format seems like a very sensible thing to do. If we do that, should we turn in into a mechanism where the users pick one and we setup only that or we enable env based config as a common one while adding the additional option to one fo the few different file based configuration?

#7

:+1: Makes sense.

Me too. It is widely used by many packages across languages, simple to implement, easy to secure, and can be very flexible. I am not sure about the state of sanic-auth, but that might be another option if you wanted to provide stubs for choices. I am not familiar enough with it as a package as to whether you would want to add it or not.

A third option would be simply to provide a stub for the example decorator in the docs.

I think we all have done that. The only ones that didn’t fail are the ones that the rest of us pip install now :laughing:.

If it were up to me … I would enable the env exactly as you have it, and then allow them also a way to add file based. I have a setup that I use for dev/production that pulls the config from two files: one that is global to all my microservices, and one that is for a specific microservice. Then, those can be overridden by env if they are set. This ends up where I can either drop a file in place (my preferred method for production environments), or use docker to set the variables (usually what I do in dev). I have found this gives me a good amount of flexibility while developing, but also control when I am deploying to a staging or production environment.

1 Like
#8

I’ve made a few changes to the template since I last mentioned you about what I had in my todo list. So, tox environment is now picked from the runtime option you choose and rest of your system is setup around the same python configuration. (I think I should fix this and make it python config and then down pull it to tox level rather than doing the other way like I am doing now.)

It also supports a few different way to running your sanic app. Not just gunicorn anymore.

The most important thing to me is the fact that it provides an API that you can play around with and test your workflow before you implement it into your code. This avoids so much overhead later when it comes to debugging authentication/authorization issues. I also like the fact that if you use the RSA Public Key used to sign the tokens, you can easily do a fast check to see if your token is valid and from the right issuer without invoking the token issuing APIs. Which is amazing for microservices that are not exposed to the external world.

I saw this earlier and liked this mechanism over the others. I think for starters, I will keep this as a stub for now and going forward, we can think of a more specialized option.

Well, I broke them too :wink:

I personally would prefer to externalize these parameters into something like consul and use it during the app’s runtime. However, I like your idea of having a drop in replacement. Let me add a mechanism whereby the user can say if they want to have the option of using an external config file and based on that, I will add an extra hook to fetch and update the App config based on external file content.

1 Like