As it stands currently serverless is the future of application development . With services like serverless.com and the benefit these being to developers in terms of low / no touch deployments , massive cost savings and infinite scalability, it's clear that serverless is here to stay.

Many companies like us - Moosend.com - have invested years in creating microservices on Servicestack. Typically the service platform can't dictate the infrastructure architecture. Therefore now that we have decided to move a lot of our services over to AWS and Lambda we face the dilemma of having to pick between lambda and servicestack as the two are not compatible as it stands.

I vote to create a serverless.com template for a simple example on deploying a servicestack service on aws lambda. I personally spent days on trying to do this myself but without much luck. An experienced Servicestack developer can probably do this in a day or so and this will massively future proof the framework we all love so much.

Thanks
Yannis

IHttpRestClientAsync exposes various method-specific async methods as well as SendAsync.

SendAsync has a cancellation token parameter in its signature:

Task<TResponse> SendAsync<TResponse>(string httpMethod, string absoluteUrl, object request, CancellationToken token = default);

while other methods (GetAsync, PostAsync etc) don't

https://github.com/ServiceStack/ServiceStack/blob/6366ba9316d1380b920cd854042bef8649f630c5/src/ServiceStack.Interfaces/IHttpRestClientAsync.cs

Implementations of IHttpRestClientAsync (like JsonHttpClient) do have the methods which support then token:

    public Task<TResponse> GetAsync<TResponse>(IReturn<TResponse> requestDto, CancellationToken token) =>
        SendAsync<TResponse>(HttpMethods.Get, ResolveTypedUrl(HttpMethods.Get, requestDto), null, token);

https://github.com/ServiceStack/ServiceStack/blob/9de810436e0a589be002dff5bdfcf203081e6a0b/src/ServiceStack.HttpClient/JsonHttpClient.cs#L699

and in fact all the method-specific implementations just call SendAsync under the hood.

Without token-aware methods exposed through an interface I cannot use them in a depencency-injected IServiceClient and its derivatives. They are only usable if you access JsonHttpClient directly and not through its interfaces.

Right now I'm using this workaround in my DI setup:

public interface ICancellableHttpRestClientAsync : IHttpRestClientAsync
{
    Task<TResponse> GetAsync<TResponse>(IReturn<TResponse> requestDto, CancellationToken token);

    Task<TResponse> PostAsync<TResponse>(IReturn<TResponse> requestDto, CancellationToken token);

    Task<TResponse> PutAsync<TResponse>(IReturn<TResponse> requestDto, CancellationToken token);

    Task PatchAsync(IReturnVoid requestDto, CancellationToken token);

    Task DeleteAsync(IReturnVoid requestDto, CancellationToken token);
}

    private class CancellableJsonHttpRestClientAsync : JsonHttpClient, ICancellableHttpRestClientAsync
    {
        public CancellableJsonHttpRestClientAsync(string baseUrl) : base(baseUrl)
        {
        }
    }

    services.AddSingleton<ICancellableHttpRestClientAsync>(new CancellableJsonHttpRestClientAsync(myEndpoint));

Why not expose these methods in a library-provided interface?

When using raw SQL, due to having complex CTE queries, that does not start with SELECT but rather with WITH, the SqlList method loads everything in one go.
This is unfortunate when the result set is large, and we would like to process one row at a time, and avoid the memory overhead, and waiting time, of getting the whole result set at once.

The SelectLazy would have solved this problem, if it had supported any arbitrary SQL, but it does not.
According to the documentation SelectLazy can do this if the SQL starts with SELECT however, for our case the query is a CTE, so it starts with WITH.

Having a SqlListLazy that allows us to run complex CTE queries efficiently would solve this.

Alternatively, change SelectLazy to recognise CTE queries that start with WITH

For documentation on the WITH syntax in PostgreSQL see https://www.postgresql.org/docs/11/queries-with.html

Currently OrmLite's Sqlite adapter supports creation of foreign key constraints when using the ForeignKey attribute on your data classes. However the foreign keys aren't actually enforced at the database by default (for 'compatibility reasons').

I don't know when Sqlite added the feature, but it will check constraints if you send a pragma at the start of each connection:

http://www.sqlite.org/pragma.html#pragma_foreign_keys

I've tested a simple workaround by sending the pragma as a SQL statement in my service methods), and the constraints are enforced as expected. Cascade deletes work as expected too.

However this isn't optimal if you want your service code to be db-agnostic (it's also a bit inefficient if sent as a separate db request, rather than pre-pended to the first request). It would be great to have this enabled at the dialect level so that developers can use db-agnostic code and patterns related to constraint checks and foreign key delete and update operations, regardless whether they are using Sqlite or the other databases that support foreign keys.