We're going on an Adventure!

[blackfyre]

The original gallery has a feature which offers 20 random artworks from the search. We can easily reproduce this feature with an actual database.

Tasks:

• [ ] Create the handler
• [ ] Get 20 random artworks from the DB
• [ ] Present

[ajistrying]

Hello! I'd like to take this if possible? Might take me some time given I'm new to golang web dev specifically, but I think i can grok things if I spend some up front time focusing on understanding the application.

[blackfyre]

Hi @ajistrying !

Thanks for expressing your interest in the project, you are very welcome to contribute! I'll write up a couple of notes soon for you get your bearings around the project!

[ajistrying]

@blackfyre Thank you, really looking forward to those notes, in the meantime I'll be digging into the code. 😄

[blackfyre]

In a lot of cases, we've followed the general guidelines pocketbase gave us, so part of the documentation is there, under pocketbase as a framework 😉

[ajistrying]

Sounds good! For the env vars necessary for running the application, what're the recommended services for each? (i.e. smtp, recaptcha, etc)

[blackfyre]

Well... today was shot to hell... About the env vars, you're free to use any service you want, it's up to you! I usually configure a dev env with mail trapping like mailhog, for storage: something S3 compatible like minio... There's one caveat, which I haven't figured out yet... as you can see the textual part of the content is included in the seed files, but there's an 8 GB+ repository for the images, that's a bit hard to distribute and the currently configured storage is meant for the subsequent production environment.

[ajistrying]

All good no worries!

Awesome, will get those setup, any thoughts on recaptcha?

Couple questions to your image data distribution point:

• Could a separate read-only storage solution for these images be an option for development?
• Can the amount of seed data be so that we don't have to manage 8GB+ of image data? Maybe separating seed data according to specific parts of the application might make sense where a contributor can download only the necessary seed data for what they're specifically working on. Hopefully this one makes sense!

[blackfyre]

Problem is mostly what Pocketbase supports 😅 I'm thinking about an image generator that would seed the target s3 compatible storage with random low res images so that it doesn't take hours... The problem is the amount really...

Another option is to differentiate the seed data based on the app context (dev/staging/production), but that would obfuscate a lot of problems with the source data itself...

[ajistrying]

I think I'm a little confused on what you mean by what Pocketbase supports being a problem. We're using a s3 compatible storage for these images, where would Pocketbase come in for the storage of those images?

Is all of the seed data necessary? Could we pare it down to something more reasonable and still have the application function normally?

[blackfyre]

Once the the initial start of the app is done, a wga_data folder appears, that contains the sqlite db files with the seeded data. After that PB expects to find the corresponding images in the configured S3 compatible storage. Tbh, nothing adverse happens, it's just that images can't load and the site appears to be broken.

The RO storage you've mentioned doesn't really work as PB expects to write to said storage.

Seed separation doesn't really work in this case as it means that a whole feature flag / circuit breaker structure would have to be set-up and I'm not too keen on that.

[ajistrying]

Ah okay I understand now, yeah a RO db definitely wouldn't work here. Also didn't fully realize that locally the db being used is a sqlite one.

I really like the image generator idea...seems like breaking up the seed data is more work than it's worth, and the image quality isn't super critical to most development work I'm assuming?

[blackfyre]

PB uses a read optimized sqlite approach and in terms of data volume this site is on the lower end so it's not going to be hindered by sqlite. I'm also thinking that an image generator or something like that would be the best option at the moment.

[blackfyre]

Soo... the image generator should be up soon with a docker-compose file in tow for creating a localized dev env. The docker-composer file contains a minio and mailpit servers. The initial image seeding in a local env takes about hour to process and around ~6GB of space.

[ajistrying]

Nice, will take a look and continue dev setup this weekend, thanks for talking through this with me 👍

[ajistrying]

Hmmm, not sure what might be happening, but I setup the project in the following way:

1. Set up an env file with bucket info, mail server info, and some admin info
2. Ran goreleaser release --snapshot --clean after configuring .goreleaser.yaml to build for my M1 macbook
3. Moved my .env file into the generated dist directory where the executable lives
4. Ran ./wga serve and I can navigate to the Pocketbase instance

For some reason at step 4 is where I realize that my .env variables are propagating into the pocketbase instance because the s3 config isn't there, nor is the mail server info. Any idea where I went wrong in the setup steps I took above? Thanks

[blackfyre]

Some info that might help solve the problem:

• you can run go run . serve from the project root, the goreleaser command is only necessary if you want to have a binary on hand
  • in this case the .env file should live in the root of the project, where the .env.example is
  • alternatively you can run ˙air serve` for the same effect, that automatically rebuilds the temporary app whenever there's a code change
• the contents of the .env are read both when the initial setup is running and in run-time
  • specifically the S3, mail server and default admin creation are read from the env when doing the initial setup
  • the rest is used in run-time

If you need to force the setup again, just delete the wga_data folder and run air serve again.

[ajistrying]

go run . serve solved my issue, I think it might have been something with goreleaser's build process, but I can see all of my env vars in pocketbase correctly. 👍

Is it expected that when visiting the application at http://localhost:8090 I get this response right after setting things up?

[blackfyre]

Nope, something is seriously wrong on your end...
The expected behavior is the same as at https://wga-uat.blackfyre.ninja/ Tbh, you're the 1st with Apple Silicon to try this 😅 and I've got literally no idea where it falls apart... I've setup this application on multiple systems already (windows & multiple linux distros) and neither gave me such issues. I'm also assuming that missing colon in the url you've posted is a typo instead of a copy & paste...

Are there any messages in the terminal after starting the app? (apart from the notices about the api/admin urls)