My company has a very large site made up of lots of distinct sections, each maintained by their own team (e.g. browse pages vs checkout).
Does it make sense to build a separate Progressive Web App for each section, or do we need to unify our approach and build only a single Progressive Web App?
Think about progressive web apps in the same way you think about native applications. Then think if makes sense to have separated applications and you'll get your answer.
Being specific with your question I think you distinguish between some kind of info pages and service pages you currently keep under the same domain. If this is so, be aware that progressive web apps are unique by origin (protocol + domain name + port) and need HTTPS enabled so keeping separated progressive web apps can incur in additional infrastructure costs.
Nevertheless, this does not mean the same teams you have now can not maintain different parts of the same application.
If you are moving from a legacy website to progressive web apps (PWA), then I'd suggest you start small. Build a serious but not mission-critical PWA that performs a single function and go through the development/deploy process of building a PWA with Service Workers (fast reload and offline), home page installation and push notifications. This is no different than introducing any new technology to an organization (e.g, cloud, microservices, devops, et al).
A progressive web application is an application. And that PWA can potentially be installed on the home screen of a smartphone. I don't think you want users to have separate apps/icons on their home screens for your web "site".
Imo, your website should be a collection of microservices that are accessed via the web, not really a collection of applications. This gives you much more flexibility and agility. Combining microservices with PWA can be quite compelling for both content producers and users.
Related
I have an MVC application in production, hosted on Azure. Now I would like to develop Mobile app using Xamarin.Forms and Azure Mobile apps. The goal is to use the same database on both mobile and web. After reading available documentation online, I haven't found the way that would suffice my needs. I would like to know what is the fastest and best way to achieve that.
Is it enough to add necessary fields to existing entities that I would use in my mobile apps? Meaning adding fields like: Version, CreatedAt, UpdatedAt, Deleted and add another Id field of type string ex. MobileId (because current database uses autoincrement ids of type integer). Is this approach Ok, or should I do it some other way?
Any suggestion/advice would be much appreciated.
Azure Mobile apps is an accelerator and a way for devs not familiar with backend development to quickly create a backend for mobile apps. Since you already have a backend, you can simply add API methods in your MVC app that your mobile app will call. You will not benefit from some of the features that the SDK provides but you won't have to change your database structure.
You don't need to create a backend mobile app and in most cases you probably shouldn't. Is your app hosted in app services? If so there really wouldn't be any major differences between leveraging (and expanding as needed) the controller layer of your application. In most cases the datastore won't need to change to accommodate a mobile app vs a web app. Usually you want the datastore to change and evolve based on the features that you want your application to support as opposed to the plataforms that are consuming those features. It's usually a good idea to add an abstraction layer(s) to shield the datastore from platform specific requirements.
That being said there are a few Azure services that you should consider adding to make your life easier when developing Xamarin apps:
Notification Hub (provides an abstraction layer over the platform specific push notification services for ios and android).
App center (provides very useful telemetry data about crashes and errors that occur in your Xamarin clients).
App insights, it provides really good additional telemetry data with very powerful out-of-the-box visualization and querying capabilities for both web apps and mobile apps (I would configure app center to feed its telemetry data to App Insights).
If you provide me with more details about the application I would be happy to give you more detailed suggestions but the recommendations above serve as a good starting point for almost all the mobile application projects that I have encountered.
I'm developing with Azure Mobile Services (using SQL Azure) to provide a backend for both IOS and Android mobile apps and a PHP website.
My question is now that now custom apis have been introduced is it considered best practice to wrap everything up in custom api calls rather than e.g. using the CRUD table operation scripts directly from apps or websites?
Additionally for data access from a website should you lock down access to stored procedures and only exec via custom apis, to enforce a consistent approach no matter who the consumer is?
While I appreciate that custom apis and the table scripts are restful it still isn't clear how to architect a solution in the most efficient, reliable way that can enforce business rules in only place allowing each process only one entry point e.g. you have a stored procedure exec'd by an api called from the mobile apps. If the website calls that stored procedure directly without going via the api it could have unwanted side effects because other logic steps will have been missed.
I'm relatively new to Azure so forgive me if I have just missed something fundamental here. I've read many blogs and tutorials but they rapidly go out of date.
Many thanks
In my opinion the great feature of azure mobile services is the push notifications (to ios, android, wp). If you are not going to use that, there's no great advantage to use WAMS
(Windows Azure Mobile Services).
But it's a good choice using Windows Azure as backend since it's easy to scale up /down. In this case, you could create a Webapi and host in a Web Role. As it works with http, you can easily create Restful services and call them from your apps (ios / android).
I will developp and host an e-commerce website based on Asp.Net MVC4 (with several SQL Server Jobs).
I think use Azure in order to stay in Microsoft's world and avoid dedicated server management.
The package Web Site Shared with 1 site / 5Go SQL Server Database / 200Go Bandwidth is very interesting with the price based on 12 months.
But i don't know if this configuration is enough specially on the bandwidth.
What do you think of ? Did you use Azure with this type of application ?
Regards,
Guillaume.
If you want to develop E-Commerce application you will have to secure customers' sensitive data i.e. credit cards, address details etc. via secure connections (HTTPS; in many countries this is legal requirement). For that reason you will have to have SSL support.
Azure Website do not support SSL for custom domains. However, they support SSL for *.azurewebsites.net DNS name. So if your E-Commerce application DNS will be, say, my-ecom-app.azurewebsites.net then it's fine. Otherwise, I would not recommend Azure Website solution yet (I am sure SSL support for custom domains on Azure Website will be implemented).
Azure Cloud Services, on the other had, have full support of SSL for custom domains.
One of the really good websites to check Azure features and development roadmap is ScottGu's Blog
Azure Web Sites do not support SSL and I really don't know of any successful e-commerce site that does not run SSL for at least part of the website. If you really want to host your e-commerce on Azure today your only real choice is to run Virtual Machines for your web front end servers and use them for your DB or use SQL Azure.
We developed platform called Virto Commerce that does just that, MVC4 website hosted on Azure. There was also a need for SQL Jobs (indexing, payment processing, cart cleanups and so on) for which we used WorkerRole (instead of WebRole). WorkerRole and WebRole can actually be combined as part of a single deployment, however it is better to use a different instance for worker roles. In our case WorkerRole acted as a scheduler for multiple jobs defined in the database.
The challenge with WorkerRoles however is to make sure they scale well when new instances are added. So the workload needs to be distributed between multiple instances. This is done through the use of queues and blob locks, where each job is now split into two, one that schedules and partitions the work and the second that actually picks up the next partition and completes it.
Hope this helps!
PS: Virto Commerce is now available as an open source project on codeplex, go to http://virtocommerce.codeplex.com
I'm working on a project that involves two web portals hosted on the same IIS 7.5 server:
(A) MVC4 web application for administration
(B) Mobile MVC4 web application with jQuery Mobile
Both are retrieving the data from the Web API based services hosted on other IIS server.
Now I'm about to add manipulation of images that are managed on Admin portal (A) and displayed to clients within Mobile app (B). Images will be added/changed dynamically with higher frequency.
I had two solutions in my mind:
Store all images in database on the server that hosts Web API as byte arrays, and send them on demand as base64 strings - render them on mobile app pages as base64 strings:
Can set any kind of security restrictions and integrate them well with MVC
Pages would be rendered in one request
Transferring from Web API to Mobile app
What happens to caching?
Store all images on the server that hosts both (A) and (B) in some shared folder, include them in rendered pages as regular tags.
No transfer between WebAPI and Web server
Caching of images
Several requests for each image on the page
Thing that I have to take in consideration as well is that there will be native iPhone app that will do the same role as mobile web app, meaning it should have access to same set of images.
Any thoughts would be appreciated on this, I'm looking for best practices solution, a guide, hints, or anything that I could use.
Also, if option 2. is suggested, what is the best place to store images to be shared between two portals?
Thanks!
I would recommend you going with option 2 and store the images on some shared folder. The best would be to have a specific application that will act as CDN hosting all your static resources. According to YSlow best practices this CDN should be hosted on a different top level domain than the clients, thus allowing cookieless access to those lowering the bandwidth consumption.
I have a few questions concerning how to create a VoiceXML application.
I found some nice tutorials, but there are still some questions:
-what's a good development environment? I wanted to use VS08, there should be under C#, a project called "speech", but it doesn't appear, do I have to install the speech server local too in order to use this? (I would prefer some kind of visual workflow)
-what's the ending? is it .xml, .aspx, or .speax? I couldn't get that.
-how do I run the voicexml? it's at the speech server as an application, any further steps?
These questions are all over the map on the basics, but I'll try to provide some pointers:
what's a good development enviroment?
You will likely be building a web style application. So a VS08 ASP application is a reasonable starting point.
do i have to install the speech server local too in order to use this?
Yes. There are a variety of platforms that support VoiceXML. Nearly all are designed specifically for telephone calls (VoiceXML's main purpose). There are a few free implementations, but most are commercial. I believe the Opera web browser has some VoiceXML functionality. I've seen settings for it in their configuration, but no direct experience.
what's the ending? is it .xml, .aspx, or .speax ? i couldn't get that.
Endings usually aren't relevant, except maybe to tools. I don't believe VisualStudio provides any direct support for VoiceXML. Some browsers do care what mimetypes are provided.
how do i run the voicexml? it's at the speech server as an application, any furhter steps?
Does this mean you are looking at the OCS/Lync product line ? I believe their IVR in that suite does support VoiceXML as well as a few other APIs. The product should contain basic setup and configuration information. More information on Lync:
Microsoft Lync site
Wikipedia
One of the main goals of VoiceXML was to decouple the rendering of the voice application (on a speech server) from the voice application itself. This allows you to serve VoiceXML pages from any web server, anywhere, using any technology stack you want.
If you just want to learn VoiceXML in general, developer sites like Voxeo's Evolution allow you to render your voice applications on their voice hosting infrastructure. You configure your developer account to point to an initial VoiceXML page served from your external web server. In return, you get a phone number to call. When you call it, the hosting infrastructure fetches your initial VoiceXML page from your web server.
(I don't know offhand if Microsoft Lync hosting services are available yet.)