QuoteJustOnce:
Few takeaways for you:

1. I want to assume Nodejs for the backend (api) and React for the frontend? yes? if so why? which will lead to further questions.
2. React is just a library. Are you using pure react or a full-fledged React-framework?
3. which brings me to: 95% of the time you don't need external modules to achieve something. while they make the work easier (a bit), they tend to increase the bundle size by a bigger margin, leading to heavy and slower apps.

if you had attached an image of how you wanted the reporting and activity dashboard to look like, then i would have told you how best to approach it module-lessly. I have actually presented graphs and realtime- charts using zero modules (native js data structure + html elements would suffice). Take that to the bank!

bet9ja:


The problem with his approach and choice of technologies is that, the legacy project will be a pain in the ass for any engineer that will later work with the project. He could have used Nextjs which was built on top of React Lib for building production application, and Nestjs which is the best JavaScript backend framework. These are fully fledge frameworks that enforce a design pattern and easy for continues integration and deployment.

Thanks bro...I started learning Nestjs few days ago and it will be my next stop for my next project. I know well about Nextjs but never learnt anything about it. On this current project, there is no going back, I have created close to 100 API endpoints with Express, and for the frontend, I can't even count number of pages I have creted already. I love it here on Nairaland because I know people like you with better experience will add something valuable to the table.

As this are, you may use https://www.chartjs.org/ for your reporting.

QuoteJustOnce:
Few takeaways for you:

1. I want to assume Nodejs for the backend (api) and React for the frontend? yes? if so why? which will lead to further questions.
2. React is just a library. Are you using pure react or a full-fledged React-framework?
3. which brings me to: 95% of the time you don't need external modules to achieve something. while they make the work easier (a bit), they tend to increase the bundle size by a bigger margin, leading to heavy and slower apps.

if you had attached an image of how you wanted the reporting and activity dashboard to look like, then i would have told you how best to approach it module-lessly. I have actually presented graphs and realtime- charts using zero modules (native js data structure + html elements would suffice). Take that to the bank!

qtguru:
Use a chart library bro, this is a client's project not your assignment. Use what works than building from scratch

Try Apexchart

donproject2:


Yes...node for apis, react for frontend. By full-fledged react, did you mean using framework like Nextjs?

Reporting like creating tabulated results for the users and dashboard like the one Power BI can build. I have other tools I can use for the two but they are overkill, besides, these are tools that have their own server and needed to be installed either on a VM and link with the website or I pay for a service that will help me host them.

bet9ja:


The problem with his approach and choice of technologies is that, the legacy project will be a pain in the ass for any engineer that will later work with the project. He could have used Nextjs which was built on top of React Lib for building production application, and Nestjs which is the best JavaScript backend framework

QuoteJustOnce:


Yes something like Nextjs would have given you an all-in-one package (fe + api). So i wonder why you had to make a standalone api (server). Unless of course you plan on making the api available publicly or would want to sell it later as a paid integration. else, it's an overkill. You also have to think of portability and scalability. if you are deploying several tools on servers minus your application, then how fast can you move these to a new server, if the client would want to switch servers? then the financial aspect, why should you incur extra cost just to host some kind of tool that your app needs. There are special cases for these, so you have to decide is it worth it? If it isn't, then an all-in-one solution would be the better and faster option. Once again reduce your need for overbloated node_modules, unless absolutely required without another way out, client project or not. The world is moving towards leaner bundles (that's why we now have stuffs like Astro) and if you can help it, do it. it pays in the long run.

donproject2:


I wouldn't combine FE and BE with any all-in-one package though, that was the reason I moved away from PHP which I started my Backend journey with. I love the Idea of API sitting separately on its own, I may want to build mobile apps that will consume the API endpoints later in future, it will be nice if by then I only need to focus on the front end aspect. I will start using Nestjs plus GraphQL for my BE moving on, and may be Nextjs for the FE.

The thing is, deploying many tools on servers shouldn't be an issue for large organizations, I worked with a Fintech company in my previous job and our main clients are banks. They own servers and they give us enough servers to work with, separate server for application, another for database, ETL gets its own, reporting and Power Bi also get their standalone server and there are ways we make them speak together. Coming from that background, I know the benefit of using separate server for deploying different tools and its downside. When I started the project, I was considering buying a VM from any of those websites that give cloud computing services and host many of those tools there. On consideration of price and my target clients, I knew it will be too expensive to go that route, if not, there are great Reporting and Charting tools that those big banks use which I can effortlessly deploy on my own VM.

On leaner bundle that you stressed, I know react with so many dependencies one has to install will not be sustainable, I know the size of the project will get unreasonable larger as the project get more functionalities, I am moving away from it soon. I don't know much about ASTRO you mentioned but I will surely do research on it.

And, if you don't mind, I don't mind having your contact, I am seeing you as someone I just need, if not as a mentor, as someone I can have around because you seem to be steps ahead of me. Thanks in advance.

QuoteJustOnce:


Good catch i like how you think outside the box, but PHP damn!. Well using Nextjs as a case study, uhmm, it doesn't work the way php works. In summary, as you may already know, it allows you write api functions and then bundles them outside your frontend app. So it's more like you still doing dedicated fe + api except that it abstracts the api side for you and also allows you to manage both inside one codebase. And yes, you can still consume the api endpoints later in the future because it does provide endpoints like your regular nodejs and you can do your regular GET, POST, PATCH etc. Heck you can even rate-limit or secure with an API key should you choose to sell the api on a per-user or per-bandwidth basis. You options are unlimited. The most important takeaway being you can manage all these codes in one place (good for future/legacy development) and then you don't have to worry too much about servers and the hassles that come with it e.g. security and best practices. Astro is very nice especially with their architecture called "Islands". you should definitely look into it. It removes a lot of bottlenecks that would occasionally spring up using traditional react or even Nextjs.

Steps ahead of you? I'm flattered but not really. Just that i've worked with too many teams and seen too many use-cases where "unanticipated" issues often neglected would then pop up and throw a wrench. I use prontonmail as my handle.

donproject2:


Good morning, do you please have any cheap SMS API service you can recommended. The ones I am seeing are quite expensive. Thanks in advance.

GREATIGBOMAN:

Twilio

donproject2:


That's SendGrid I guess, their service charge is around $0.1 per SMS for Nigeria...

donproject2:


Good morning, do you please have any cheap SMS API service you can recommended. The ones I am seeing are quite expensive. Thanks in advance.

donproject2:


That's SendGrid I guess, their service charge is around $0.1 per SMS for Nigeria...

GREATIGBOMAN:

Why not use email instead as a replacement for the sms thingy since you're looking for a way to cut costs? >

QuoteJustOnce:


Hi there, to be quite frank, SMS is the last resort to communicating with your customers (unless you've got big money) cos it's freaking expensive when you want reliability. Fun fact, even with big money, you still have to approach the key players for discounted pricing else your big money turns to small money soon.
Major names i've worked with are Twilio and AWS Pinpoint for their insane reliability; but once again expensive not because they are expensive (no pun intended) but because of our weak currency. There are many others like the homegrown "smartsmssolutions" but not quite reliable in my opinion.

GREATIGBOMAN:


Is there no Nigerian version?

donproject2:


I have that in place already. My choice of SMS option is because of the type app I am building...my client will prefer Verification Codes being sent to mobile numbers instead of emails.

QuoteJustOnce:


if you can find a way to integrate firebase (and like using firebase and don't mind getting locked to firebase) into your app, then you can use

spark plan:
$0/verification up to 10k times a month.

pay as you go:
a) standalone sms auth at $0.06/verification
b) complete identity package at $0/verification until you hit 50k active users/month

both options being cheaper than twilio and aws

donproject2:


I have that in place already. My choice of SMS option is because of the type app I am building...my client will prefer Verification Codes being sent to mobile numbers instead of emails.

GREATIGBOMAN:


Why not discuss the cost with your client?

Since it's not a personal project financing something like this shouldn't be your problem.

You should tell the client the cost of getting a good sms API

if they can't handle the cost then they use the email alternative.


If you use a cheap service you may end up losing this client when the project goes live and the setback from your cheap sms api solution starts surfacing

QuoteJustOnce:


if you can find a way to integrate firebase (and like using firebase and don't mind getting locked to firebase) into your app, then you can use

spark plan:
$0/verification up to 10k times a month.

pay as you go:
a) standalone sms auth at $0.06/verification
b) complete identity package at $0/verification until you hit 50k active users/month

both options being cheaper than twilio and aws

truthCoder2:


Implement a firebase admin-sdk that creates a user on firebase then on success, creates same user on your database. Update your user data with the uid returned from firebase before final transaction commit. When you want to send a message, you fetch uid from your message and pass props to the relevant firebase function.

You still have the chance to handle your authentication or allow firebase handle same from the frontend

QuoteJustOnce:


Yes something like Nextjs would have given you an all-in-one package (fe + api). So i wonder why you had to make a standalone api (server). Unless of course you plan on making the api available publicly or would want to sell it later as a paid integration. else, it's an overkill. You also have to think of portability and scalability. if you are deploying several tools on servers minus your application, then how fast can you move these to a new server, if the client would want to switch servers? then the financial aspect, why should you incur extra cost just to host some kind of tool that your app needs. There are special cases for these, so you have to decide is it worth it? If it isn't, then an all-in-one solution would be the better and faster option. Once again reduce your need for overbloated node_modules, unless absolutely required without another way out, client project or not. The world is moving towards leaner bundles (that's why we now have stuffs like Astro) and if you can help it, do it. it pays in the long run.

QuoteJustOnce:
@donproject2

I'll highlight your concerns in "strong" text and my answers in black

Moving on. Before I start learning new tools, I always love to be convinced that such tool is worth my time and may be my money.
Without arguments, Nextjs is one of the best frontend frameworks, no cap! A few comparison videos on YTube will clear your doubts. These days they even work together with the React to ensure any new React features are incorporated. One good example would be internationalized routing by default i.e. setting up different locales for your project. So a user in France sees your app in French and a user in Nigeria sees it in English, or one in Spain sees it in Spanish. Of course you have to provide the content or use something like i18n but then Next will automatically detect the locale and serve the appropriate page; without waiting for the page to load and have the user select the appropriate language. If you think about it deeply, that's more like server-side logic for static pages; 2 different paradigms that shouldnt naturally coexist and Next makes it happen.

I remember what you said about all-in-one package (fe + api) , I never knew Nextjs has that capability. This literally means I can eliminate Express for building APIs with NExtjs(I believe I am not wrong).
Yes, you aint wrong. In fact, you could build out your API's only without frontend and then that would be a direct replacement for an Express API app. Which means you could do FE only, BE only or both if you wish to.

I could separate routing and the actual API functions (controllers) and matrch them together later, for cleaner code, I know with Next, folder structure (inside the api folder created by Next) and the name of the file serves as the API endpoint when needed to be called from the Frontend. This is cleared out
Yes, Then there is the more advanced one called the Edge API routing. They dont' use the native Nodejs runtime but the Edge runtime i.e. they are built with standard web apis. And you can do one powerful thing with this.... Streaming!

I could create Middlewares that must return TRUE in order to allow next function called close to it to be called, i.e I can use a kind of authentication on selected routes, these routes are only accessible if the middleware called before them returns TRUE. Can you tell me I can do this with Nextjs as well.
Oh yes, Nextjs has middlewares as you would do in Express and more. Authentication? check. Bot protection? check. A/B testing? check. Localization? check. If you don't like the automatic locale detection mentioned above, then you could use middlewares to serve the correct content for a locale.