Для сборки .Net (только Windows) и .Net Core требуется только установить соответствующий SDK.
Для сборки .Net Core можно использовать Docker или любой другой инструмент (в том числе Jenkins)
Пример Dockerfile:
FROM microsoft/dotnet:2.1-sdk-alpine AS build-env
WORKDIR /app
# copy csproj and restore as distinct layers
COPY nuget.config ./
COPY src/example/*.csproj ./
RUN dotnet restore
# copy everything else and build
COPY src/example ./
RUN dotnet publish -o out -c release --no-restore
# build runtime image
FROM microsoft/dotnet:2.1.1-aspnetcore-runtime-alpine
WORKDIR /app
COPY --from=build-env /app/out ./
ENV ASPNETCORE_URLS=http://*:80
EXPOSE 80
ENTRYPOINT ["dotnet", "example.dll"]
А еще Кассандра делает задержки на каждый отдельный запрос до 150мс, рандомно похоже.
Cassandra написана на Java. Рандомные тормоза — это похоже на GC.
Как альтернативу моэно еще рассмотреть Scylla, случайных задержек не заметил. Плюс производительность выше, т.к. написана на c++.
Преимуществом перед aerospike будет то, что Scylla, за редким исключением, полностью совместима с драйверами и языком cassandra.
Согласен. С точки зрения рантайм производительности, graphql теряет здесь преимущество.
В зависимости от API, в graphql еще можно выиграть на размере ответов, но это уже в редких случаях даст что-то существенное.
По моему, GraphQL стоит больше рассматривать за его другие преимущества: гибкость запросов и статическая схема — этими преимуществами он ближе к SQL, чем к REST, и как он вписывается в общий процесс развития компании, особенно, если она большая.
Все-таки его создала компания у которой начались проблемы больше организационные в разработке и поддержке API и фронт-систем, нежели связанные с производительностью софта (хотя и здесь они были, т.к. еще не было HTTP/2).
К тому же есть отличные инструменты, которые сильно помогают на этапах анализа и разработки, как playground и voyager
Только graphql-go, по сравнению с маршалингом в json и одним REST сервисом, увеличивает время обработки в 1.5 раза на очень простом тесте, а при более сложных, скорее всего, будет еще медленнее. Но это будет только несколько миллисекунд. В зависимости от задачи, это вполне допустимый минус.
Из-за принципа использования graphql и различных паттернов, как dataloader с кэшем, можно получить даже прирост производительности, по сравнению с использованием множества REST сервисов, для получения одинаковых данных на клиенте.
Для сборки .Net Core можно использовать Docker или любой другой инструмент (в том числе Jenkins)
Пример Dockerfile:
Cassandra написана на Java. Рандомные тормоза — это похоже на GC.
Как альтернативу моэно еще рассмотреть Scylla, случайных задержек не заметил. Плюс производительность выше, т.к. написана на c++.
Преимуществом перед aerospike будет то, что Scylla, за редким исключением, полностью совместима с драйверами и языком cassandra.
metabase, к сожалению, не поддерживет ClickHouse и Apache Cassandra.
В зависимости от API, в graphql еще можно выиграть на размере ответов, но это уже в редких случаях даст что-то существенное.
По моему, GraphQL стоит больше рассматривать за его другие преимущества: гибкость запросов и статическая схема — этими преимуществами он ближе к SQL, чем к REST, и как он вписывается в общий процесс развития компании, особенно, если она большая.
Все-таки его создала компания у которой начались проблемы больше организационные в разработке и поддержке API и фронт-систем, нежели связанные с производительностью софта (хотя и здесь они были, т.к. еще не было HTTP/2).
К тому же есть отличные инструменты, которые сильно помогают на этапах анализа и разработки, как playground и voyager
Результаты:
goos: windowsgoarch: amd64
pkg: ser/graphql_bench
BenchmarkGraphQLHTTP-4 2000 891501 ns/op
BenchmarkHTTP-4 2000 593000 ns/op
Разница ~0.3 миллисекунды
Только graphql-go, по сравнению с маршалингом в json и одним REST сервисом, увеличивает время обработки в 1.5 раза на очень простом тесте, а при более сложных, скорее всего, будет еще медленнее. Но это будет только несколько миллисекунд. В зависимости от задачи, это вполне допустимый минус.
Из-за принципа использования graphql и различных паттернов, как dataloader с кэшем, можно получить даже прирост производительности, по сравнению с использованием множества REST сервисов, для получения одинаковых данных на клиенте.