15,991,071 members
Sign in
Sign in
Email
Password
Forgot your password?
Sign in with
home
articles
Browse Topics
>
Latest Articles
Top Articles
Posting/Update Guidelines
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
quick answers
Q&A
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View C++ questions
View Javascript questions
View Visual Basic questions
View .NET questions
discussions
forums
CodeProject.AI Server
All Message Boards...
Application Lifecycle
>
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Work Issues
Design and Architecture
Artificial Intelligence
ASP.NET
JavaScript
Internet of Things
C / C++ / MFC
>
ATL / WTL / STL
Managed C++/CLI
C#
Free Tools
Objective-C and Swift
Database
Hardware & Devices
>
System Admin
Hosting and Servers
Java
Linux Programming
Python
.NET (Core and Framework)
Android
iOS
Mobile
WPF
Visual Basic
Web Development
Site Bugs / Suggestions
Spam and Abuse Watch
features
features
Competitions
News
The Insider Newsletter
The Daily Build Newsletter
Newsletter archive
Surveys
CodeProject Stuff
community
lounge
Who's Who
Most Valuable Professionals
The Lounge
The CodeProject Blog
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
help
?
What is 'CodeProject'?
General FAQ
Ask a Question
Bugs and Suggestions
Article Help Forum
About Us
Search within:
Articles
Quick Answers
Messages
Comments by nickpreston24 (Top 1 by date)
nickpreston24
25-Feb-24 15:26pm
View
I would recommend keeping your .NET and SQL backend, considering the high investment and also considering using Firebase via C#. Firebase is just a database. No need to throw out working code.
Also, you will have to migrate your data from flat SQL table structures to basically to giant JSON docs in Firebase. Be absolutely certain you want to lose the strengths of SQL before you jump to the more trendy JSON doc storage models like Firebase, MongoDB and others.
Personally, I don't think you should put all your eggs in one basket. Try both, and see which works for what use cases.
As a contractor, I've always been forced to put 3d data into 2d SQL-scapes and used to dream of magical solutions like Firebase/Mongo to get me out of SQL Hell. I've since learned that SQL is just fine for transactional, flat data like invoices, orders, loan schedules, logging, etc.
For something requiring nesting, JSON dbs are good at those things, but pretty awful at querying efficiently while maintaining potentially duplicated copies of docs.
If you really need hefty, nested persistence in the form of JSON and simply cannot model everything in SQL (and why would you?), then try something like Neo4J graph database, or something more comprehensive like SurrealDB.
Finally, it sounds like you learned Flutter. Don't base your backend decisions on Flutter's need to juggle JSON like so many other popular frameworks like React. What I mean by "JSON juggling" is, you will have to not only maintain your persistance 'state' in your DB(s) of choice, but also have to maintain JSON 'state' in the UI. I would avoid this at all costs (htmx.org) and just have my API return bits of HTML, or, at worst, use either templaters like nunjucks or something that stays mostly out of the way, but can still be used on mobile like Svelte. Don't be a slave to a UI framework, if you are (many of them create more problems). UI should be both a representation of your persisted state and a remote control for the user, NOT a JSON manager, in my opinion.
What I like to do with C# is write little Services that do specialized work. In your case, I'd write one Firebase service to rule them all, then inject it into whatever API or UI you desire (and throw that sucker up in your Nuget registry of choice). Write once, cry once.
I hope this helps in your future endeavors.
Regards,
Nicholas Preston
https://peerlist.io/nickpreston
My stack: https://github.com/nickpreston24/trash-stack