John Costa
a283bc1bcd
I think this could be how we generate other lists Problems: - Knowing it's a location is good because you can do nice stuff on the frontend. - Same for contacts & events. So a good alternative, is to still use this type, but perhaps change the database such that all lists live within the new tables (lists, image_lists). But have special tags. This would also make it easier on the AI I think.
Running the backend
- Create a
.env.dockerfile, which must contain the following.
OPENAI_API_KEY=openai_key DB_CONNECTION=postgresql://postgres:password@database:5432/haystack_db?sslmode=disable
- Use
docker-compose upto spin up the containers.
You should be able to access the backend through port 3040
Methods
For now, we cheat and add a userId header which if os type UUID. Use the auto generated test one (fcc22dbb-7792-4595-be8e-d0439e13990a).
GET /image| Returns all of the users image, including tags, links and text any image contains.GET /image/{imageId}| Returns the actual image, use this to display images in the UI.POST /image/{imageNameWithExtension}| Sends an image to the backend, saves it and sents it to open ai to later process.
Architecture
- The user posts an image, which gets saved on our database (all data, including images are saved on DB).
- We listen for table event creation, and we can process this image by sending it to OpenAI.
- After OpenAI responds, we write to the database.
This means that for now, we don't have a notification system to tell the user when their image is done processing. But will do in the future.