I'm trying to migrate a WebAPI application to Azure Functions.
I have searched on the net and haven't found anything equivalent to ExceptionFilterAttribute supported in Azure Functions.
Does this mean that to migrate this feature, we should wrap the code of every function in try catch blocks and then run the same code to process the Exception? Are there any other workarounds?
You can use Function Filters in Azure Functions, particularly ErrorHandler.
Just keep in mind
This features is still in preview. Please be cautious using this in production applications.
Related
They look pretty similar, both provide a visual interface to compose lambda functions, data sources and sinks, etc. to serverless applications.
By comparing the information from aws website I failed to tell the differences between those two products. Could anyone help to give me some insights about the differences?
I have tried read the docs and use cases of both products but failed to find the differences. I would like to know when I should choose Application Composer and when move to Step Functions?
The Application composer will help you create your serverless application. You will put your services together, and then you can deploy them.
The step function does completely different things. It orchestrates already-created services. In a step function, you will set how/when you want to execute your steps (lambda function, dynamodb integrations, etc..), and then you can execute the step function anytime you want.
Anyone successfully integrated AWS AppSync with Laravel?
I am new to AWS AppSync but good experience with laravel.
I am trying to implement an offline-app feature in my mobile app and the mobile API part is what Laravel handles.
I looked into AWS AppSync but all they are talking about is dynamoDB and graphQL. Someplace it says i need to use AWS Lambda.
I really can't get a grip on how to properly implement this.
Any suggestions or pieces of advice are greatly appreciated.
I have basic experience with graphQL
Thanks
I checked a few video sessions and found HTTP endpoint can be used as a resolver. is this the proper way?
If I use HTTP as resolver can I still use the real-time features?
links
https://aws.amazon.com/appsync/
Laravel is a PHP framework, so I think the two options you would want to consider would be HTTP and Lambda data sources.
Lambda can be something of a catch-all for data sources: you have absolute control over what you call, how you do it, and in what language you do it. You just have to set up a Lambda function and create a data source in the AppSync console pointing to it, then have your Lambda function interact with your framework however it needs to.
I'm not terribly familiar with Laravel myself, but I believe HTTP is also a totally viable option. I would think this would be the way you want to go, as it cuts out the added complexity and latency of a Lambda function between AppSync and your end destination. A tutorial for setting one up is available here: https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-http-resolvers.html
In either case, real time updates will be absolutely available to you.
I have seen the sample projects on your website for Dexie.Syncable such as sync-server and sync-client and they all seem to write to a datbase directly vs interacting with a web api. I am looking for a little help in where to get started beyond the examples on the website. The api I am trying to write a gateway for is dreamfactory
Also it looks like version 2 beta has had many improvements to Dexie.Syncable
I would recommend to build a new server-project based on either WebSocketSyncServer.js or the github repo of sync-server. However, I cannot give the details on how to call REST APIs instead of working directly towards database or memory. I would suggest using ES2016 async/await since your API calls are asynchronic.
Maybe you could try getting more help on https://github.com/nponiros/sync_server by filing an issue there.
I learned to love how LINQ enables set operations on collections. I'm not saying that I plan to shun traditional RDMBS, because I do need it for reporting. There are NoSQL alternatives out there, but they seem to all need to fire up a separate service.
What I looking for is something local where a DLL can create a database and perform CRUD on it. As mentioned, I'm not going to report out of this, just internal data store. The main application that will be using it is in C#.
I'm hoping that someone can give me a lead. If not, if there is anyone willing, we can start a open-source project for it. I'm not interested in commercial products.
Thanks,
You can run RavenDB in embedded mode inside your .NET application - no need for external services or anything.
And RavenDB supports Linq....
My company is looking into writing a custom application that will need to perform many list item queries across multiple site collections. It will need to run for WSS 3.0 and it 'would be nice' if it worked on WSS 2.0 as well. It won't be designed for MOSS/SPS but again it 'would be nice' if it worked on these platforms. There is no restriction on which .NET version should be used for the solution.
For this type of application, what would be better: the object model/API or SharePoint web services? The primary factor I'm considering is performance, followed by features and functionality. Thanks!
Object model is better as you can gain access to additional features and the full detail of the list items, such as the version history.
The object model is also better for performance (as long as you dispose() your spsite and spweb objects properly).
The Sharepoint object model has some differences between 2 and 3, but if you look at the reference for v2 then it will also work fully with v3.
The web services have not changed at all between v2 and v3, which explains why they do not have any new features of v3.
The reason the object model will win on performance is that you will not be serialising the data as Xml and then transmitting a large chunk of Xml, and then deserialising the Xml. The object model spares your memory and bandwidth.
The first thing to consider is "will my code run on a sharepoint server or remotely ?"
If it's running remotely, you don't
have any choice, use web services
If it's running on a sharepoint
server, I would suggest using object
model, as performance will be
better, you'll have access to more
API and authentication will be
easier (=automatic).
+1 to the other posters.
If you decide to go the OM route then you can compile for both WSS 2.0 and WSS 3.0 from the one source. These should get you started.
Developing for Sharepoint 2003 using Visual Studio 2008?
How to reference two versions of an API?
Can the OM be used inside an Infopath form? Currently I'm using the web services to pull in the list data I want but I would rather use the OM.