@IOM
Nothing here yet.
Nothing here yet.
No blogs yet.
I don't think using HAProxy for calling 3rd party APIs is normal. I don't think there is any issue with either of your current tools, but I would use axios because you can create specialized sub-instances (perfect for APIs!). const instance = axios.create({ baseURL: 'https://some-api-domain.com/api/' , timeout: 1000 , headers: { 'X-Custom-Header' : 'foobar' } }); // every HTTP request made using the instance object // will include the specified defaults export default instance // other file import someApi from './some-api' export async function getContacts ( ) { const response = await someApi.get( "contacts" ) return response.data } export async function addContact ( data ) { const response = await someApi.post( "contacts" , data) return response.data } export async function getContact ( id ) { const response = await someApi.get( `contacts/ ${id} ` ) return response.data } Axios is isomorphic (works in browser and in serverside), also checkout the middlewares (called interceptors ). I recommend not using fetch because fetch is very low-level and does almost nothing right by default for typical 3rd party JSON APIs. https://medium.com/@shahata/why-i-wont-be-using-fetch-api-in-my-apps-6900e6c6fe78
I don't know Ramda. And honestly, some of that code looks pretty obtuse. But if your lead developer and team majority want to run their team this way, then you need to learn Ramda. From their perspective, they are using the most elegant, readable, and/or maintainable solution they know about. They might be wrong, but your job isn't to prove them wrong. Your job is to be a team player and ship the product. Resistance to Ramda may result in you being labeled a Blub Programmer . In this case, a programmer who is skeptical of more powerful languages or tools. You might acquire a reputation on the team as the guy who writes "basic code" or the guy who isn't a team player. Both of those are bad. Your options are basically: learn Ramda, show them something better, do nothing and hope relations don't sour, or start searching for a new team. If you choose to show them something better, you need to be willing to accept if the team doesn't find your replacement better. You need to respect that the cost of switching might be too high. You need to really understand Ramda and demonstrate that understanding of Ramda so you can give a competent explanation for why your solution is better. If they're not convinced you understand Ramda, you'll solidify your reputation as the Blub Programmer or you'll look like you're wasting time Bikeshedding or arguing against things they think are obviously non-negotiable. I don't recommend attempting to show them something better unless you have a really solid case. Free Online Book that covers JavaScript and Ramda. Don't worry if you don't understand some of the later parts anyone who does is probably pretending anyways: https://github.com/MostlyAdequate/mostly-adequate-guide If your team is still using PHP, they might be interested in the Non-standard PHP library: https://github.com/ihor/Nspl What if the team majority is not on board with Ramda? What if it's one or two developers and the rest just tolerate it? My answer does not cover that scenario, but remember first and foremost that you must be a team player and you need to ship the product.
NodeJS is production ready, but also have a look at Elixir (Phoenix), golang, and Crystal if a small memory footprint is really important for specific microservices. How sure are you of your strategy to convert 600k lines of code to NodeJS without bringing the 1.7GB memory footprint with it? Fair warning about rewrites, they can take unpredictably long durations of time. Is each microservice reducing the size of the grails monolith (things that must be compiled, loaded, intellisensed, etc.)? Can you build the services without making local dev a nightmare to setup? Can you convert the Grails to API only and have a NodeJS render the HTML templates via nextjs or nuxtjs? Best of luck!
No need to choose, I use the ES6/ES7 versions when they exist and import the lodash functions on a case-by-case basis for the huge number of them that don't exist natively in ES6/ES7.
If you're looking for Pub-Sub, Kafka might be more scalable, persistent, and reliable at the cost of being maybe slightly slower and more difficult to setup. Redis supports ACID transactions via Lua scripts, so it blocks across all redis instances for the duration of the Lua script. Laravel uses this to ensure queue jobs are worked on by exactly one queue worker. Redis should not be your "source of truth" database unless you really understand what you're doing and can validate it meets your use-case. It's great for key-value store, cache, pub-sub, and queues. Memcache is a good alternative for key-value store, sessions, and catching, although I don't know how it handles ram limitations differently than redis. Beanstalkd is a good queues database, better than redis for this purpose (although the makers of redis are coming out with an add-on module built for queues: https://github.com/antirez/disque/issues/190 )