Async/await and the future of Vapor

[0xTim (Tim)]

@karamba

It really would help to look at for example Entity framework.

Looking at the Entity docs the first model they show looks like

using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

namespace ContosoPets.Domain.Models
{
    public partial class Product
    {
        public int Id { get; set; }
        [Required]
        public string Name { get; set; }
        [Column(TypeName = "decimal(18, 2)")]
        public decimal Price { get; set; }

        public ICollection<ProductOrder> ProductOrders { get; set; }
    }
}

With DB data right in the model. Isn't that exactly the same thing?

[indiedotkim (Joachim "Kim" Baran)]

@karamba

For example how would you mock such object for unit testing ? It cannot live without DB and therefore any logic in your code even very high level like api controllers are not unit testable.

I am not familiar enough with Vapor to comment on this directly, but I am working with Python/Django and they do offer unit-testing for their framework by instantiating a temporary database just for the tests. You can populate that test-database during set-up, if necessary, and then you can run your tests without having to mock instances from the database. The only thing that you have to mock are data that you are testing with.

Again, I am not knowledgeable enough about Vapor to make a particular insightful statement here. However, I think that if Django can do it, then it would be nice if Vapor can do it too.

[karamba]

Try this

@0xTim

  [Required]
        public string Name { get; set; }
        [Column(TypeName = "decimal(18, 2)")]
        public decimal Price { get; set; }

You really picked a bad example. Entity Framework does allow to do this but is is not required and even discouraged. Data model in well designed applications is a clean object with no any attachments and all db related code is in the logic. OnModelCreating. in case of dotnet entity framework.

[karamba]

@grey280

I’ve been following the async/await PR, super excited for that to be available. Great work!

@0xTim

OpenAPI support - this is a personal one for me, but I'd like to see first class support to make it easy to integrate

I’ll throw a +1 here, as well - it’s a super helpful technology, and I think the ease of integration with other stacks that it offers would be a big benefit.

Like Dontet for example with Swishbuckle or NetSwag. Most our products implemented OpenApi only in debug builds. That let us to autogenerate all kinds of clients without affecting the production version.
I do both front and backend development and the absence of OpenAPI in 4.0 is the very major pain in the rear that really adds development time