I'm calling it DjangoGreen 3/n

Last modified 2020-12-16 22:55 SGT

With the help of the DigitalOcean customer support, I managed to overcome the biggest obstacle (so far and hopefully stays that way!) for my idea. Which means I can reveal the actual project name I wanted to call it -- DjangoGreen.

The idea for my app goes like this.

1. You have an idea for a SaaS app.
2. You chose GitHub, Django, Docker, Stripe, and DigitalOcean for your stack.
3. You type in the project name and press a button. Two things happen.
4. You get a working v1 SaaS app instantly on DigitalOcean and its codebase inside a GitHub repo.

That's the idea. Basically, it's an idea-to-v1 instant SaaS builder.

If you want to have gamechanger features in your SaaS, you have to write those yourself. What DjangoGreen is responsible for are the mission-critical, standard SaaS features. DjangoGreen gives you a jumpstart in getting your v1 in front of your potential customers.

What was the biggest obstacle?

I can now deploy a Django v2.2 on DigitalOcean's App Platform (DOAP) using Docker. The biggest risk I thought was that it might be very difficult or impossible to deploy Django via a Dockerfile on DOAP.

I found tutorials on deploying:

1. Django on DOAP and,
2. Dockerfile on DOAP.

But definitely none that are Django via Dockerfile on DOAP.

I insist on deploying via Dockerfile because I want a universal format for deployment. GitHub may look and work slightly differently from their competitors. Underneath it all, GitHub and their competitors can work with your code so long as you choose Git. Git is pretty much universal and an open format for version control.

Similarly, I want Dockerfile to be the universal format for deployment. Choosing Docker acts as an enabling constraint too. It prevents DjangoGreen from being too coupled with DigitalOcean's App Platform.

I'm relieved I manage to overcome that obstacle despite the lack of documentation.

So what's next?

I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly.

-- Paul Graham at Six Principles for Making New Things

I only wrote down some brief steps for my crude version 1 in my linear app.

The key persona I have for the user of DjangoGreen is the product developer. My notes consist only of the developer flow using v1.

Developer Flow for v1

1. Login using GitHub (Assume developer has a GitHub Free account and DigitalOcean account)
2. Type repo name (Assume name is okay)
3. Press Submit button (Assume this button triggers both creation of GitHub repo and the deployment on DigitalOcean)

This results in the following:

• A new GitHub repo with the code
• A deployment on DOAP as well
• The site has a Coming Soon! landing page

That's pretty much my notes. I do want to add that the deployment on DOAP might not happen so seamlessly.

From the email conversation I have with DO's customer support, each app's first-time deployment may require the developer to manually key in additional info in the DigitalOcean admin panel. Subsequent deploys can happen automatically.

On to today's summary of obstacles and time spent.

Blockers and Papercuts

For the first-time reader, this is a quick recap of the 4 categories of obstacles

🛑 Absolute Blocker: I cannot get past this (yet?) and it's critical to building the app
🚧 Critical Slowdown: I took more than 10 mins to figure this out and it's critical to building the app
🦟 Annoying Mosquito: Took more than 10 mins or unsolvable but not critical
🧘🏻‍♂️ Zen: Solved in less than 10 mins and not critical

🧘🏻‍♂️ Zen
Not any today.

🦟 Annoying Mosquito

Two DEV related markdown issue.

• I cannot appear to do indentation for nested numbered list.

Action taken: Accept and move on. 🤷🏻‍♂️

• I realize that to have a hero image or cover image, I need to place the cover_image: link_to_image within your triple-dashed lines. Aka your front matter

like this

---
series: Building GoGreen on DigitalOcean App Platform Hackathon Series
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/tn54kn95003u4gzbbvn8.png
---

🚧 Critical Slowdown

The past 2-3 days I have spent hours figuring out why I cannot even get the landing page to work and working with the DO customer support. So this was the critical slowdown.

I had to piece together the exact sequence of manual steps, and make the right configuration and code changes before this was solved. I feel like I can write my own DigitalOcean how-to guide at this point.

The next step is to figure out GitHub login. I will probably go with installing the plugin django-allauth to solve this.

🛑 Absolute Blocker

Not at this point.

Time spent thus far 🕒

For first-time reader, this is the section where I explicitly share the time spent. This is to set realistic expectations for readers and myself.

Total time so far: 11 hr
Dev work so far: 7.25 hr
Writing so far: 3.75 hr

2020-12-16 Wednesday

1. Write a 3rd post in the series in DEV (1.25 hr)

2020-12-15 Tuesday

1. Add a frontpage app, static, and staticfiles folder in codebase to experiment (1.25 hrs)
2. Make the landing page to work finally (1 hr)

2020-12-14 Monday

1. Work on environment variables and gunicorn successfully. Fail to get the admin page up though (1.5 hrs)

2020-12-13 Sunday

1. Trying out Nate suggestion involving Docker and Django on DOAP (0.5 hrs)
2. Writing second post on DEV (0.5 hrs)
3. Trying out the codefresh example as suggested by Dikshith (1 hr)
4. Wrote a new ticket and purchased a managed DB cluster on DigitalOcean (0.25 hr)

2020-12-12 Saturday

1. Trying out how to deploy from GitHub to DOAP and other engineering stuff (1.5 hrs)
2. Writing on DEV and figuring out how to write in DEV (2 hrs)