Docker postgres config for NextJS template

[JoeOakhartNava]

Ticket

Related to #267

Changes

Added docker config for Postgres

Context for reviewers

This does not add ORM or more complex DB integration to the NextJS template. The goal of this change is to create a better starting point for teams using this template that encourages them to favor a more reliable Postgres docker container over a less reliable Prisma implementation.

Testing

Created a new application from the revised template. Verified that it built the docker images and ran the application as expected out-of-the-box.

[doshitan]

Since this does not cover the full scope of #267, let's not say "Resolves #267" which will close the issue, but "related to"/"part of"/etc

[doshitan]

I think we should follow a similar pattern as is established for the other templates:

• https://github.com/navapbc/template-application-rails/blob/main/template/%7B%7Bapp_name%7D%7D/docker-compose.yml.jinja
• https://github.com/navapbc/template-application-flask/blob/main/template/%7B%7Bapp_name%7D%7D/docker-compose.yml.jinja

(they are not quite normalized yet, but everything should eventually converge)

Which here looks like:

• Drop the separate container file
• Update the command
• Drop the explicit network declaration

Given the Next.js template is often used to build client-side only apps, could also make the DB part conditional on a template variable, but I think we can cross that bridge later as it's easy enough to delete or comment out the DB block if you don't want it.

[doshitan]

The app template should provide a db-migrate script for setting up the database, like the other app templates, e.g. https://github.com/navapbc/template-application-rails/blob/7ac4e6636faefaf70add7cc166336960ade8fdf7/template/%7B%7Bapp_name%7D%7D/bin/db-migrate

[JoeOakhartNava]

Could you give me any more context on this? I used the separate Docker image for the DB because it seemed like the easiest way to pull in initial schema with a sql script. I see that the example you reference runs a Ruby tool called Rake for DB migration. NextJS doesn't have a direct equivalent. What would it look like to follow the pattern you describe without Ruby?

[doshitan]

Could you give me any more context on this?

See https://github.com/navapbc/template-infra/blob/ee6fe10f27716b9f434960052d86634dee85d6fe/template-only-docs/application-requirements.md?plain=1#L11

While it does not seem like we are looking to support a DB in hosted environments here, we should build towards the established patterns. Ideally this should be ensure the postgres client/libraries are available in the container environment, provide a init-db make target (rails, flask), etc. so there's a more completely supported workflow even locally. But that doesn't necessarily have to be done here.

What would it look like to follow the pattern you describe without Ruby?

It should be appropriate to the application framework. In this case if we don't have an actual DB library to use, we should use psql directly (see https://github.com/navapbc/template-infra/blob/ee6fe10f27716b9f434960052d86634dee85d6fe/template-only-app/db-migrate as a reference, though will need some slight adaptation to support the local development usecase).

[doshitan]

We can drop this section. The current workflow suggested is still pretty much to develop in a template instance first, then backport to template. I think we'll want to centralize/coordinate doc updates across all the templates for updates to this.

[JoeOakhartNava]

How would a user who has pulled down template-application-nextjs know to look to the documentation you reference? I'm not seeing any guidance on the development process within template-application-nextjs, which creates a confusing situation for a developer who wants to contribute an update.

[doshitan]

A good question that needs a consistent (and somewhat centralized) answer across Strata templates. There's a variety of things that need to be pulled together, so let's avoid scattering info further for the moment.