Frontend - Server communication
Hi, I´m trying to self host the docker hub images in Azure Container Apps, and I´m nearly there, but struggeling with some frontend <-> server communications (I think).
The server -> db communication is functioning, i.e. I can run
yarn database:reset from the server, and it runs through it´s loop ok.
I also connect to the frontend url and get greeted with the login modal, but when I try to write something an error ApolloError appers in the upper right hand.
Is this error related to connectivity issues? And is there some way to test from within the containers?
Running the latest docker images.
71 Replies
It looks so! Your frontend (executed by your browser) should reach out to your server url.
You can set the REACT_APP_SERVER_BASE_URL at build time (if you pass it as env variable) or at runtime (it's handled by inject-runtime-env .sh script) make sure this is the command used to run your FE in your Dockerfile:
CMD ["/bin/sh", "-c", "./scripts/inject-runtime-env.sh && serve build"]
From what I can debug it´s open from the twenty-frontend to twenty-backend:3000, and the REACT_APP_SERVER_BASE_URL is set at build time as an env variable correctly.
I think the problem lies from the other side, that the FRONT_BASE_URL env in the server don´t route correctly.
twenty-backend:3000 is unlikely to work
this is your local dns in case you are transitting from docker to docker
the frontend is executed on the client side (in your user browser)
so it needs a public DNS
for example for Twenty cloud it's api.twenty.com
aha.. That makes sense. I´ll try some more later and hopefully succeed. If interested I could clean up the terraform code afterwards and share it.
Would love it!
Success! Thanks! one more question though. How do I initialize the server and db tabels for a production environment?
Is it
start:prod or something, ref https://github.com/twentyhq/twenty/blob/d016e5ff03555fcc49884ea3479df230d2fffc26/packages/twenty-server/package.json
Running yarn database:reset runs ok. But trying to login with [email protected] gives error
looks like something is broken while initializing your database
what does yarn database:reset gives as an output?
got it working using yarn nx database:setup:prod
though something is iffy, got lots of 500 errors from time to time. Page refresh sort of fixes it for a small time
I was getting the same errors as you when trying to self host it on docker.
did you resolve it and get it working?
Im super keen to try this CRM out.
Your server is throwing 500, what do you see in your server logs?
Sorry about the late response, time zone issues..
Error logs complains about
But doing yarn command command workspace:health -w 20202020-1c25-4d02-bf25-6aeccf7ea419 gives "Workspace is healhty" 🤔
your database does not looks to be initialized. What are you using to host your postgres database? twenty-postgres container?
yes, twenty-postgres:0.3.0. Just did a yarn database:reset just before this
ok, could you post the output of yarn database:reset?
/app/packages/twenty-server # yarn database:reset
Performed 'Dropping all schemas...' successfully
Performed 'create schema "public"' successfully
Performed 'create schema "metadata"' successfully
Performed 'create schema "core"' successfully
Performed 'create extension pg_graphql' successfully
Performed 'create extension "uuid-ossp"' successfully
Performed 'create extension "postgres_fdw"' successfully
Performed 'create extension "wrappers"' successfully
Performed 'create extension "mysql_fdw"' successfully
Performed 'create airtable "wrappers"' successfully
Performed 'create bigQuery "wrappers"' successfully
Performed 'create clickHouse "wrappers"' successfully
Performed 'create firebase "wrappers"' successfully
Performed 'create logflare "wrappers"' successfully
Performed 'create s3 "wrappers"' successfully
Performed 'create stripe "wrappers"' successfully
Performed 'inflect names for graphql' successfully
Performed 'create function graphql' successfully
and then?
still thinking
😄
are there some reference specs to the containers? currently at 1vcpu/2Gi
this should be good enough 🙂
and it should become better and better with time, we are way underestimate currently
Ok, looks perfect
is your server up?
yes
is it still complaining about missing core.workspace being missing?
Not workspace, but get some
error: relation "metadata.dataSource" does not exist when trying to create an api tokenthat's weird, can you connect to your database through psql or a postgresql UI and check what you have?
maybe you don't use the right database?
When it first fails, it then just starts a domino effect and nearly all calls get a 500
yeah got access using psql
do you see a default database with core and metadata schema
and these schema shoul have tables
it should look like this
not that fluent in psql, do you have some commands?
ok, it looks like your default database is not initialized
you only have public schema
I don't get it :p
oh ok!
makes more sense
good
can you check what you have in metadata
default=# \dt metadata.*
List of relations
Schema | Name | Type | Owner
----------+-----------------------+-------+-------- metadata | _typeorm_migrations | table | twenty metadata | dataSource | table | twenty metadata | fieldMetadata | table | twenty metadata | objectMetadata | table | twenty metadata | relationMetadata | table | twenty metadata | workspaceCacheVersion | table | twenty metadata | workspaceMigration | table | twenty (7 rows)
----------+-----------------------+-------+-------- metadata | _typeorm_migrations | table | twenty metadata | dataSource | table | twenty metadata | fieldMetadata | table | twenty metadata | objectMetadata | table | twenty metadata | relationMetadata | table | twenty metadata | workspaceCacheVersion | table | twenty metadata | workspaceMigration | table | twenty (7 rows)
so it's there
yeah
could you share your PG_DATABASE_URL?
is the user twenty?
probably worth mentioning this is hosted in azure container apps, not locally somewhere
PG_DATABASE_URL=postgres://twenty:twenty@sens-twenty-db:5432/default
looks good too
would it be possible that you have multiple replicas?
several postgres container running?
No other postgres containers.
Yeah, I´ve been searching through others issues and not found any potential config errors I´ve missed
I'm running out of ideas, this should work. How is Azure interfering with application level stuff
Could you share your Azure config?
is server container always failing the same way? do you feel that some database queries are working?
does yarn command command workspace:health -w 20202020-1c25-4d02-bf25-6aeccf7ea419 consistently returns healthy?
that's so weird
workspace:health gives success each time
thinking it might be CORS rules https://learn.microsoft.com/en-us/azure/container-apps/cors?tabs=arm&pivots=azure-portal
Configure CORS in the Azure portal for Azure Container Apps
Learn how to configure your static web app to allow cross origin resource sharing (CORS) for Azure Container Apps
mmmmh, ok, so the logs you provided for the server are actually old bugs!
all right, it MAKES sense
to check it, can you go to your server url on /graphql
Do you have an error in the browser console regarding cors?
reaching /graphql. Should I run something specific?
No cors errors
Can you show me your network tab while you reload the frontend?
oh so it's running!
As soon as I try moving an opportunity this happens. Each time
the "An error occured" is a known bug, it should not impact the app
We have a PR open to fix this, just ignore it for now
so it seems to be working 🙂
wait a sec. there some references to
strict-origin-when-cross-origin when graphql gets a 500
I was unclear. When I try moving an opportunity I get apolloerrors, and the opportunity moves back to its original placement
Have to try more tomorrow, thanks for the help so far
what do you have in your server logs when you generate this 500?
I tinkered some with Azure routing settings, and it got somewhat better. But I still get some intermittent 500 errors.
Hi @thilles, did you manage to get it working?
Yeah, late last night I had a breakthrough.
The FRONT_BASE_URL and REACT_APP_SERVER_BASE_URL were referring to old revisions of the docker containers. And each time I tried a bugfix, a new revision was created.
Once I changed the variables to reference a fqdn without the container revision part things have been much smoother.
Only thing I've seen so far is that when trying to remove a profile picture, i get an error. But I believe this is a bug more than connected.
Btw, what's the correct way of setting up the db for production use? It's still somewhat hard to tell from the self hosting docs.
After even more debugging I found that the db keeps shutting down and restarting. That´s probably why all those 500 errors and complaints that different tables don´t exist. Using image twenty-postgres:0.3.1.
Heard about that before?
It restarts without any warning? Have you tried increasing the memory / cpu of the postgres instance to see if it solves the problem? I don't see any reason why the database container itself would restart
or maybe it's a health check issue?
twenty-postgres is made for production (it's the one we use on our cloud) so that's the correct way to host a db in production right now.
(You can also use your own postgres instance on a server and configure it the same way we do in the Dockerfile)
thinking it´s a health check issue. Seeing messages
received smart shutdown request and
Type":"Warning","ContainerAppName":"twenty-postgres","RevisionName":"twenty-postgres--cmhqnjb","ReplicaName":"twenty-postgres--cmhqnjb-cd88778c-svbc2","Msg":"readiness probe failed: connection refused","Reason":"ReplicaUnhealthy","EventSource":"ContainerAppController","Count":3}this might be it! What is your health check configuration? If it's configured to get 200 like a web server, this might be the issue
Think I finally figured it out! The postgres container auto-scaled and made multiple replicas, but they didn´t replicate the schemas.
The solution was setting a max=1 option on number of replicas.
@charles any tips on how to get a new icon for the self-host docs? Making a PR for this. Thinking using the IconBrandAzure, but don´t know how that will render
@thilles sorry about the slow answer, we've merged your work today
a big thank you!
Might want to revert that @charles Found out the postgres container used ephemeral storage, i.e. the default database is wiped between restarts😬
I'll have to figure out a solution. Will post a new PR when it's fixed
Haha indeed, it might be an issue 😄
Use storage mounts in Azure Container Apps
Learn to use temporary and permanent storage mounts in Azure Container Apps
can we easily shift to a permanent storage?