i'm new to ServiceStack, so forgive me.
i'd like to know when is usefull use ServiceStack.
For example, if i've to create a console app that not exposes services, creating an appHost is not right, do you confirm?
If i understand, servicestack (and so create an apphost) is usefull if i've to create a self-hosted console app or a web app or however something that expose a service (which could be a simple authentication service)
Thanks in advance for any help
An AppHost is required for all ServiceStack Apps where you're using ServiceStack to host your APIs.
ServiceStack has a number of starting project templates at: https://servicestack.net/start
In .NET5/6 all Web Apps are Console Apps:
Some non traditional HTTP Web Apps you can use ServiceStack for include gRPC Services, Worker Services which hosts APIs in background workers
and potentially AWS Lambda as it's for running your ServiceStack App in AWS Lambda.
You wouldn't use an AppHost if you're not using ServiceStack to host your APIs, e.g. if you're just using a component in one of ServiceStack's stand-alone libraries:
ServiceStack.Redis - Typed Client for Redis
ServiceStack.OrmLite - Lightweight POCO ORM for RDBMS access
ServiceStack.Aws - Poco Dynamo and SQS, S3, DynamoDB support
ServiceStack.Azure - Connectors for Service Bus, Azure Blob, Table Storage, etc
ServiceStack.Text - JSON/CSV/JSV Serializers, Auto Mapping, HTTP Utils, etc.
Related
I know that the Azure function supports HTTP trigger and we can write a function that can be exposed like an API. I'm looking for an option to host a complete C# WebAPI project (multiple Rest endpoints including swagger definition) into a single Azure function.
Is this feasible? and supported? I see this scenario is completely supported in AWS Lambda. Where we can deploy a whole WebAPI project into a single lambda. Here is the demo of
the same.
I have watched the provided Video and I observed the same functionality is also available in Azure Functions.
As Direct way is not available like publishing the Web API to the Functions but migration of Web API to Functions is possible if the Web API is authenticated with any option like Open API, etc and using the APIM Service we can manage all the operations in it.
And as per the Microsoft Update, Startup.csand program.cs is unified to the program.cs file. So, I have added the required swagger configuration code in the file program.cs and tested it, working successful locally.
Another approach is you can call the Web APIs from Azure Functions securely, here is one of my approaches along with few other ways to do it.
Refer to #VovaBilyachat alternative solution on publishing .NET Core Web API to Azure that provides the glimpse of using Containers instead Functions.
We have a legacy SOAP webservice that is called by multiple clients.
We'd like to host a copy of the service in Azure PAAS. There should be no changes required from the clients, other than a change to the URL they call.
API Management is not an option at present. I looked into creating a custom logic app connector and got as far as consuming the WSDL but then received an error message stating that one-way operations are not supported.
What are the alternatives? Are there any example of achieving this using an HTTP Triggered Azure Function?
Assuming you're creating a new implementation for the service contract, the right way to do this is with a .NET Framework WCF service hosted in Azure App Service.
Azure Functions are .NET Core and .NET Core doesn't have an official WCF service implementation, and Azure Functions doesn't help you in any way to create SOAP endpoints. So it would actually be much harder than using an Asp.Net project with first-class WCF tooling in Visual Studio.
svcutil.exe can generate the code to implement the service from the wsdl.
I connected my swagger PetStore api to Azure using swagger Azure API Management integration.
Now that it made it in azure; Where do I implement the actual logic of querying my azure database etc?
Using swagger if I generate a Node server stub I get the following generated. But these are not available if I use API management integration.
In the Backend section I only see Logic Apps and endpoint options. I tried the Logic App stuff but it seems I need 50 logic apps if I have api that large...Am I missing something?
Maybe you need to use SwaggerHub.
The Swagger UI you are currently using belongs to the community version and should not support direct integration. Assuming there are 100 api interfaces, you need to add 100 times in azure apim.
I've been reading a few tutorials now on deploying Web Apps and API Apps to Azure. However, I am still a little unsure as to why you would use one over another.
I can create a new .NET solution with API controllers and deploy this as a Web App, so why would I specifically require an API App? Are these optimized specifically for ASP.NET Web API, where as Web Apps are for delivering HTML?
Updating the answer to current state of Azure,
App Services now replaces all Mobile, Api and Web Apps flavors as a single app framework with all the functionality rolled over to make things more accessible across application types. Currently all of Web, Mobile and Api Apps are collectively called App Services. We still offer customer to be able to create a Mobile App and a Web App in the gallery but that is basically resolve into an App Service App.
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Features for Mobile work for Web App as well such as Easy Tables and Easy API. And features for API apps like API Cors and API definitions now work on web apps as well. A customer can host a single web app to act as any mobile service or an api with all the features offered through the app services.
We also have a new service in preview particularly targeting API Apps by offering a management experience for your APIs, Basically you can control the generate try API pages, gather execution analytics, throttle and much more. Check out the feature blog to learn more about the Azure API Management Features. And yes you can host the APIs as a App Service App and hook things up with API Management.
https://azure.microsoft.com/en-us/documentation/articles/api-management-get-started/
There was a point in time when there were differences between the different app service types, but that is no longer true. The documentation now states:
The only difference between the three app types (API, web, mobile) is the name and icon used for them in the Azure portal.
So it no longer matters which app service type you choose to deploy to (unless you care what the icon looks like).
UPDATE
Function apps are now the exception. Creating a function app changes the user interface in the portal. The underlying web app, however, is no different. Setting an app setting named FUNCTIONS_EXTENSION_VERSION = ~1 turns any web app into a function app (minus the user interface in the portal).
There are many minor difference between Web API and API Apps, but the very notable and key differences are
Native Swagger implementation - When you create API App in Visual studio, swagger reference comes by default. Swagger provide very developer friendly features for API consumers to Interact with your API thru Swagger UI. Also Swagger based API's provides client SDK generation (both .Net based client and Javascript based client) which makes easy to call API's just like regular method call.
Note: Swagger implementation on regular Web API is possible manually.
Ability to publish your API Apps into Azure Market Place. Azure Market Place is the public repository for all API Apps that can be consumed freely or by charge.
this 15 minute video from Channel 9 gives an excellent overview about Api Apps.
To supplement Greg's answer, Here's an even more recent article describing the differences.
To sum up:
"The key features of API Apps – authentication, CORS and API metadata – have moved directly into App Service. With this change, the features are available across Web, Mobile and API Apps. In fact, all three share the same Microsoft.Web/sites resource type in Resource Manager."
And here's another important note:
"If your API is already deployed as a Web App or Mobile App, you do not have to redeploy your app to take advantage of the new features."
This can depend on what you are trying to do, but you would use a Web API when you are creating a service. ASP.Net Web API is a framework for building HTTP services that can be consumed by a broad range of clients. This allows you to build it not only for a web app, but have it open to connect to Android apps, IOS apps, web apps, Windows 8 apps, WPF apps etc..
So if you need a Web Service but you don't need SOAP then you can use Web API.
Here my comments:
API app:
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Web APP: An application deployed with multiple functionallity, for example
a catalog for create, update and delete customers or to create a complete ERP.
Function APP: Is very similar to API app,
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Actually you can deploy your aspnet webapi on Azure WebApp and a self host on Worker Roles.
On WebApp (former Azure websites), it will be deployed on IIS, so you can take advantage of IIS features.
As I gone over the AWS Lambda documentation, there are references on triggering services based on AWS events. I do not see references on hosting services in Lambda.
Would like to understand whether is it possible to create RESTful services using AWS Lambda for web sites to consume or not?
I can use NodeJs to develop the service.
As of the last month, the answer has changed. AWS Lambda functions can now return a synchronous response and AWS is now encouraging the use of Lambda as a mobile backend or potentially a full REST API.
Documentation is a bit sparse at the moment, but you can start reading about it here for now:
http://aws.amazon.com/lambda/whatsnew/
Amazon now supports this directly with the API Gateway service. This post is a great rundown of how to get started.
Correction :
Amazon has launched - Amazon API Gateway which used Lambda
What Is Amazon API Gateway?
API Gateway helps developers deliver
robust, secure, and scalable mobile and web application back ends. API
Gateway allows developers to securely connect mobile and web
applications to business logic hosted on AWS Lambda, APIs hosted on
Amazon EC2, or other publicly addressable web services hosted inside
or outside of AWS. With API Gateway, developers can create and operate
APIs for their back-end services without developing and maintaining
infrastructure to handle authorization and access control, traffic
management, monitoring and analytics, version management, and software
development kit (SDK) generation.
API Gateway is designed for web and mobile developers who are looking
to provide secure, reliable access to back-end APIs for access from
mobile apps, web apps, and server apps that are built internally or by
third-party ecosystem partners. The business logic behind the APIs can
either be provided by a publicly accessible endpoint API Gateway
proxies call to, or it can be entirely run as a Lambda function.
https://aws.amazon.com/api-gateway
As of today; AWS Lambda is focused on working out / responding to events like S3 put, DynamoDB Streams and also custom events [ there could be more event sources expected from Amazon ] - with heavily leveraging the STATELESSNESS style of programming.
To build out a complete RESTful Service backend using AWS Lambda wouldn't be possible or in other words AWS Lambda would be a bad choice to build the RESTful Service. You can continue to use the NodeJS and make it run on top of EC2 or ElasticBeanstalk.
The answer is Yes it is possible to build RESTful services using AWS lambda for websites to consume.
Your question has been answered by Tim Wagner of Amazon at a conference presentation where an audience member asks a very similar question to yours.
Question
"If you want to trigger a lambda function based on a regular old web request coming in from a user on the internet ... they hit an address and they sent in a bunch of query parameters ... So theres just this one stateless kind of thing that comes in with a bunch of data and then you want to trigger a lambda function off of that? ... what are the options there? ... to fire off that node.js workload?"
Answer 1
"... use something like beanstalk to create a web app. And then inside that webapp invoke the lambda functions for the portions of your workload or scenario that make sense to do"
Answer 2
"... If you're able to ... constrain your calls to match lambda's request model then you can skip that (beanstak webapp) and simply call us as if we were a web service proxy for you"
https://youtu.be/copO_JQQsBs?t=50m53s
As for the node part of your question.
The answer is yes you can develop your Lambda function using node.js
Please refer to the Webinar from Amazon below.
"The language that we have support for today is node.js"
https://youtu.be/YEWtQsqIYsk?t=25m22s
You can do almost anything (also very easily) with AWS Lambda. You can check out the below Serverless Framework: http://docs.serverless.com/v0.5.0/docs
For JAVA you can use Lambada Framework: https://github.com/lambadaframework/lambadaframework