I'm looking for advice choosing a back-end architecture for a web app. In the app, users upload tabular data from multiple files. Their data is then processed, aggregated and visualized. Data is private and each user has their own dashboard.
I believe Cube.js is an excellent choice for the dashboard, but I am wondering what back-end web framework I should integrate it with. I have experience of Django, but would use Express if it had significant advantages.
Thanks for any advice!
Cube.js is designed to run as a microservice. It means there's no requirement for you to use Node.js or Express as a stack for the rest of your backend implementation. However usually you'd need to have separate backend for storing data about users, reports and dashboards if those are dynamic. Cube.js server handles only analytic queries.
Cube.js dashboard templates are designed to work with GraphQL. So any backend web framework where there's a solid support of GraphQL will be a good choice. Most notable ones in Node.js world are apollo-server, Prisma, Hasura. Seems like Python has it's own champion as well: https://github.com/graphql-python/graphene.
Related
I have a log analysis tool as a Java based web application with html/jsp front end. Java backend receives real-time log data from few different agents/datasources and does ML/analysis and then stores insights on a file system, accessible only to Java backend. Now my users login to the system using a browser and access Java backend and insights using rest endpoints in the form of HTML/jsp reports/dashboards.
All sounds good but my users are complaining that UI is not production grade. So I am searching for different solutions to build a nicer UI experience for my users and I am looking into Power BI embedded solution.
How to integrate power bi embedded to serve insights that continuously change behind the scenes? how does it work in this use case knowing that my insights are only accessible to my Java backend and can only be served using Rest End points?
Also are there any better alternative solutions?
I am developing an application which is used by multiple clients and the main goal of the app is to be used online. But a specific requirement is, it should be able to work offline too (only for a single client(s) in an emergency situation and for short time - 24 hours maximum). now I am using Django REST framework for backend and Jquery/AJAX frontend for GET and PUT etc. requests which update PostgreSQL DB on the backend. Now little research on the internet suggests the I should use PouchDB on the frontend and/or CouchDB on the backend. But my questions are:
Is it really possible?
If yes, then which DB should be used for the backend database?
When the offline client become available online, how we can synchronize the data generated online?
Can we cache some data on clients machine for offline availability purpose?
Is it still possible to use PostgreSQL for the backend? (I really want to use it !)
I am planning to use Firebase database and want to know how it fits in to the following scenario.
lets say I have a browser app, android app / iOS which uses Web Services to get / insert data, web services talks to the Data Base and returns data to the client.
This way I have to write code once in my web services and all the clients use that to retrieve and insert data to the database.
If I want to use Firebase, will I be following the same approach of having webservices between the client's and the Firebase DB.
I have done some sample Firebase examples where it it gets data from database directly without web services and in this approach we have to write our logic on each client (Web browser/ android app/ iOs app).
I have looked into this article
https://firebase.googleblog.com/2013/03/where-does-firebase-fit-in-your-app.html?showComment=1480073224245#c464815735109872173
The Pattern 2 has the server concept but that does not look appropriate in my scenario.
Can I have my web service and Firebase database and get data Synchronization capabilities.
Correct me if I am wrong and please suggest the approach I need to take.
Thank you for your valuable suggestions in advance.
Thanks & regards,
Rao Burugula
The article you link gives you the most common options for integrating Firebase into your app. Pattern 2 is the easiest way to use the Firebase Database and run your own server-side code:
In this model the Firebase Database sits between the app on the user's device and your back-end code. By using this model, you can still get all the benefits of the realtime synchronization, security rules and scalability, but also have back-end code that runs in a trusted environment.
Of course you can also go for a more traditional three-tier model, where your app server sites between the devices and the database. But in that case the Firebase database won't have direct interaction with your app anymore, so you'll have to take care of the realtime aspects of the synchronization (if you want those) in your own code.
I also recommend reading the Google Cloud documentation on using the Firebase Database and App Engine's Flexible Environments. The architecture described there is the same, but a bit more up-to-date:
I have just created my first token based web API with Django-Rest-Framework and it has worked really well for my mobile applications.
I am about to start creating a website based on Django, but I would like to reuse as much of my API code as possible.
The options I can see are:
Create a basic Django application that consumes my DRF API, would have to add basic auth to my api?
Create a third application which contains all my models and logic and then import the code into the API and website application.
How do you normally approach this kind of code reuse with Django?
This answer is based on my personal approach on the problem, both on industry and academic scenarios.
I value software decoupling. As such, I want to build smaller components, as reusable as possible. While presented with a similar problem, I've built the following components:
Django Rest Framework with authentication based token and complete REST API for all models;
Mobile application that interacts with the server using REST;
Web Application (in my case with AngularJS) that interacts with the application using REST.
This approach allows to have different teams working each on their own (backend, mobile, web). I could enumerate tens of advantages of adopting such approach, but I've paved the way and you can consult literature if needed.
Good luck
Forgive my ignorance, but do people build websites with Microsoft Dynamics CRM?
I have a potential client who says that is the technology they will use for a new web project, for which I would be doing the HTML templating. I want to learn all I can as I am new to this particular system, but I can't seem to find anything related to web building and CRM. Is it more likely the client is using another piece of technology that they are neglecting to tell us about?
Any experience or insight about this process is greatly appreciated!
You can't build website using MSCRM, but you can build ASP.Net website using CRM content easily. The API provided by MSCRM is a set of web services, that can be queried in a website to populate pages content.
Also, you can directly query the Database if you want ReadOnly content, and only for read-only content, because it is not supported to update/create data using SQL connections.
Note that it's required to have the external connector license to use any data in the CRM, thru the API and even thru direct SQL queries.
I have built a website using .NET, utilising the CRM4 API and database. All the website did was to submit queries to CRM using the CRM web services and metadata web services, and get data back. This company was already using CRM for their back end, so it's much easier for the front end to use the same database as well since it's a simple one.
The alternative would be to create an intermediate connector between the 2 systems -- backend and front end, which is not as efficient (for our case anyway).