Firebase-powered app with web service code - web-services

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:

Related

back-end architecture to integrate with Cube.js

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.

Build a website in sitecore and make it offline

I want build site using Sitecore(7.2) and also make it offline. Our requirement is not to use headless CMS. Is there any way to build or make it offline?
Internet websites cannot be delivered 'offline' without having all possible data delivered to the device so that it no longer needs to connect to the internet. This sounds less like a website, and more like an app that somebody would install?
If so, you probably DO need to look at headless and building an app that connects to the APIs for updates.
You might need to be more specific about the business use case because it seems contradictory to want to use a web application software that delivers web content, without using headless, and works without the web.
As already suggested that internet websites cannot work offline so either you have an app or intranet website.
Considering as an app you can consume sitecore OData apis for Content/Media however it will not work for Presentations and you have to implement your own mobile designs based on Xamarin or native.
For odata related information you can refer below link:
https://doc.sitecore.com/developers/90/sitecore-experience-manager/en/the-odata-item-service.html
Once you get the response from api, you can locally store it in your local db of app

Login/Registration functionality in cq5

I need to create register/login functionality in CQ5. There are three ways
1 - The register/login functionality should be prepared as web service hosted on a Java Application Server and then we can consume data from web services.
2 - The functionality should be prepared as web service based on RESTFull that hosted on CQ itself since AEM is developed around the REST principal and REST web services is certainly one which will be supported. So I believe RESTfull web services can be hosted with CQ5.
3 - Why do we need web services? I do not think it requires web services since my application is not going to communicate with other application and it dont want to expose any services to outside world. Why don't we create register/login functionality as we do in normal web application. Can we create a OSGI bundle that invoke databases to store user details for register/login functionality?
I would go for 3rd option but my concern is AEM is not the place to build our business logic to carry out functions that are not related to content rendering.
which option would you choose and why? Kindly share your ideas and thoughts. I am just looking for best solution to develop register/login functionality in CQ.
Thanks
I think i am late to the party but it might help someone. Yes, you can very well create rest webservices in CQ and they work well. So, you can take that approach.
The way to go about implementing login/registration would be how it is done OOTB but OOTB is also bad in the way it implements it so you have to make modifications to overcome that.
1) You need to register and Authentication handler with CQ. If you are looking for a sample there is a form authentication handler source that you can look at.
2) We have integrated out Auth handler with Active Directory (AD). Since AD is supported by default, so it is easy to integrate with Auth Handlers.
3) Next you need to create a user login token for which you can look into TokenUtil class of CQ or if you are looking to develop SSO, you can look into SSO code that is packaged OOTB.

where to use web services

I am discovering webservices to impliment in my asp.net website. I visited many sites about Why use webservices and read many articles and found out that web services are good when you have something that is used frequently without loading your page.
I want to know some other example scenarios where web services are used.
Whether i can use web services in sending an order form to database or it is just for textbox box auto completion like google and etc.
Note: I know web services can be used from mobile, web or desktop applications.
But My question is When do i use web service in ASP.Net Application?
Some articles read so far
Codeplex
How to create a Web service using Visual Studio.net
w3school
On a Large Scale, Webservices are basically written, when you want to expose your database, your code, to some other user.
By exposing database, means, suppose, you have a large collection of all the pharmaceutical companies in a given region, storing details in db like, medicines they produce, their policies etc etc. And now, you want people to use it(possibly your paid Client, or simply free access to anyone). So what you going to do? Obviously broadcasting working connectionString to your database will be a disastrous move.
So what you do is to make few methods on top of your db i.e. CRUDE operations and expose these methods in your WebService i.e. someone can interact with these methods through a URL and fetch data or send data or both.
Most general use of WebServices is when you want your specific language built( say ASP.NET) logic and data to be accessible to people on different platforms.
Like mobile devices. Their frontEnd is built in fancy framework say like Titanium, but they fetch their data through a Sql Server using WebService built with Microsoft's WCF-Rest approach. They store their data, Synch their data through a WebService.
In a typical example, We had a very large shopping Website, and it was standalone i.e. we were the only users of its database, its data, its users. But then a requirement came, that certain Client wants to model it and make use of its existing data and logic, but they have got JAVA platform. Our entire system was built on ASP.NET 3.5. What to do then. We simply exposed our BAL through a ServiceLayer and gave it a fancy name ServiceBAL and lived (and earned) happily ever after.
These are some business oriented usage of Web Services.
Other simple, mere usage of webService like textBox auto completion, existing user check and so many, am sure, you must have found out during your scout.
Web services are reusable components you can use anywhere. for example suppose you are building order processing system where order can be place by mobile,web etc. So instead of creating a different function for different application or different platform it's better to create a web service of order processing system such as placeOrder or takeOrder web service and consume them on different applications.
Web Services are the means by which devices communicate over the World Wide Web.
Whether you use a mobile application, search engine or an enterprise system, the user piece of the application (the interface) resides on your device.
The data, and potentially the business rules, live on some other server on the network. How your interface communicates with the server piece is the role of Web Services.

Is it possible to make a call out to a remote server from within a SharePoint 2013 app?

I am very new to SharePoint development as well as SharePoint overall, so I apologize if this question seems like a no-brainer. I'm currently working on a SharePoint 2013 app and I'm wondering if it's possible to make a call out to some URL from within the SharePoint environment. Basically, I want to do this within an event receiver after some action is done to a list, and from there I want to make a call to some web service on my server to update my system. Using the REST API to poll the SharePoint server isn't a good option for this scenario since it won't scale very well.
When dealing with SharePoint 2013 apps you can access any resource using standardized APIs. In addition to REST SharePoint is offering the JS Client Object Model (CSOM).
In order to access data from another web than the current one, your app needs the permission to interact with the entire tenant.
If you're trying to query data from another host, you have to use JSONP because of the same origin policy.
if you are building an app using the "new App Model" for wiring up Remote Event Receivers it is possible to do anything, in which your app hosting framework/environment allows you to. If you are building a Classic App (Farm Solutions) you'll have access to perform operations which are allowable from the SharePoint servers directly...typically this is a lot as GAC deployed assemblies are granted full trust.
depending on what you are trying to do and what kind of resources you app will consume. I'd consider moving the dependancies away from SharePoint and building using the new App Model versus the older farm solutions. As you sound like you are starting in SharePoint, this gives you an opportunity to learn the new ways of doing development for SharePoint.
Lastly, you might consider building a workflow. Not sure what kind of app you are building but the new workflow capabilities include actions which can make RESTful calls. Potentially making your application a "no code" solution. Again it all really depends.