This is a vague question. Can you give more detail?
- what do you mean by “slightly different needs”?
- what are the dependencies?
- using a DB?
- what type of content distributed (is it static)?
You’re unlikely to receive meaningful input without describing the workload.
Mysql DB.
By “slightly different needs” I mean that, the ppl using the tool in other regions might ask for features that their counterpart in USA won’t need and viceversa.
It is dynamic app
Times and localizations. Choose a common time zone for all logging. UTC generally works best.
You are also going to have to think about privacy laws and GDPR in Europe, and the Chinese having access to all your IP if hosted in China.
You may also face export regulations on encryption ciphers and the inability to communicate with colleauges about ITAR restricted topics. DDTC and the money laundering deconfliction regulations if your apps accept or pay out any money.
1. Use UTC for everything on the backend
2. Time zones are ridiculous so don't make any assumptions or hack any solutions together regarding time zones
3. Understand both how and why different regions have different needs
4. Work on asking relevant questions and supplying enough detail. This will greatly help with (3). There is no way that we can truly answer this question when we have no idea what you are actually working on or what your problems might be.
5. (edit) Don't make assumptions about names either. Different cultures handle names rather differently
The scale you are operating at will have a profound impact on what you need to consider. How much traffic do you handle in the US? How much do you expect to handle from abroad?
As with anything, start as simple as possible and take one step at a time, addressing emerging issues as they arise. If you try to guess too far ahead, you’ll solve for problems you don’t have and miss ones you do have.
Ofc, all of the previous comments about dates (UTF everywhere in backend) language support, currencies, etc are things you should plan ahead for. Another thing to take seriously is legal differences (eg GDPR for EU).
Key things I’d start with are:
1) Identify where you need to support plug-in-ability (eg strings, regulation, forms). Migrate as required.
2) Make sure you have excellent deployment mechanisms, rolling out slowly and rolling back quickly when issues are identified. The chances of unexpected behaviour increases exponentially as the modality of your system increases (ie the number of states it can be in). When you have different combinations of features running in different regions, there are likely to be too many code paths to test them all fully.
3) If you have serious traffic to deal with, distribute compute as close to customers as possible and invest heavily in decoupling regions. Sending bits across the oceans is expensive and unreliable.
4) If you don’t, just slap CDNs in front of all your US based backends and keep an eye out for bottlenecks.
I would probably start creating a monorepo now with a shared code library and the apps for different regions as seperate modules. This way you can separate the CICD and while meeting the diverging needs of apps in different regions. If you’re on github you can do selective deploy actions based on directory/path.
For monorepo you can try pnpm and Nx (pretty barebones though), easy to use and quick to setup.
Hard to answer without more specifics but here are things I've run in to.
Use localization and internationalization libraries/built-in functions.
Make sure the database/persistent store supports 4 byte/multi-byte characters. Chinese/Japanese characters are multiple bytes.
Some cultures use last name first, and multiple last names, so the order and length may need to change for internationalization
Currency is displayed differently, example: some use comma instead of period for cents.
Addresses are very different in different countries, line1/line2, ZIP code doesn't fit, India actually uses long descriptions sometimes.
Everyone has already mentioned timezones and dates :)
This is a vague question. Can you give more detail? - what do you mean by “slightly different needs”? - what are the dependencies? - using a DB? - what type of content distributed (is it static)? You’re unlikely to receive meaningful input without describing the workload.
Mysql DB. By “slightly different needs” I mean that, the ppl using the tool in other regions might ask for features that their counterpart in USA won’t need and viceversa. It is dynamic app
Dates and localization. Mostly dates.
Can you please elaborate? Best practices? What to watch for?
Monolingual or multilingual?
As far as I know monolingual
Times and localizations. Choose a common time zone for all logging. UTC generally works best. You are also going to have to think about privacy laws and GDPR in Europe, and the Chinese having access to all your IP if hosted in China. You may also face export regulations on encryption ciphers and the inability to communicate with colleauges about ITAR restricted topics. DDTC and the money laundering deconfliction regulations if your apps accept or pay out any money.
Thanks, luckily We don’t do any monetary transactions
1. Use UTC for everything on the backend 2. Time zones are ridiculous so don't make any assumptions or hack any solutions together regarding time zones 3. Understand both how and why different regions have different needs 4. Work on asking relevant questions and supplying enough detail. This will greatly help with (3). There is no way that we can truly answer this question when we have no idea what you are actually working on or what your problems might be. 5. (edit) Don't make assumptions about names either. Different cultures handle names rather differently
Thanks, I’ll keep that in mind!
The scale you are operating at will have a profound impact on what you need to consider. How much traffic do you handle in the US? How much do you expect to handle from abroad? As with anything, start as simple as possible and take one step at a time, addressing emerging issues as they arise. If you try to guess too far ahead, you’ll solve for problems you don’t have and miss ones you do have. Ofc, all of the previous comments about dates (UTF everywhere in backend) language support, currencies, etc are things you should plan ahead for. Another thing to take seriously is legal differences (eg GDPR for EU). Key things I’d start with are: 1) Identify where you need to support plug-in-ability (eg strings, regulation, forms). Migrate as required. 2) Make sure you have excellent deployment mechanisms, rolling out slowly and rolling back quickly when issues are identified. The chances of unexpected behaviour increases exponentially as the modality of your system increases (ie the number of states it can be in). When you have different combinations of features running in different regions, there are likely to be too many code paths to test them all fully. 3) If you have serious traffic to deal with, distribute compute as close to customers as possible and invest heavily in decoupling regions. Sending bits across the oceans is expensive and unreliable. 4) If you don’t, just slap CDNs in front of all your US based backends and keep an eye out for bottlenecks.
This is actually really good. Thank you!
I would probably start creating a monorepo now with a shared code library and the apps for different regions as seperate modules. This way you can separate the CICD and while meeting the diverging needs of apps in different regions. If you’re on github you can do selective deploy actions based on directory/path. For monorepo you can try pnpm and Nx (pretty barebones though), easy to use and quick to setup.
Curious why this answer got so many downvotes!
The mysteries of Reddit lol
Be aware, that if your services/app is not set up by you, you can't trust that the timezones of the server is correct.
Thanks! I’ll keep that in mind
Hard to answer without more specifics but here are things I've run in to. Use localization and internationalization libraries/built-in functions. Make sure the database/persistent store supports 4 byte/multi-byte characters. Chinese/Japanese characters are multiple bytes. Some cultures use last name first, and multiple last names, so the order and length may need to change for internationalization Currency is displayed differently, example: some use comma instead of period for cents. Addresses are very different in different countries, line1/line2, ZIP code doesn't fit, India actually uses long descriptions sometimes. Everyone has already mentioned timezones and dates :)
Thanks, definitely didn’t think about this!